Hi all!
Yesterday NEAR, a project that my colleagues and I have been working on for the last 2 years.
NEAR is a blockchain protocol and decentralized application platform with a focus on performance and ease of use.
Today I want to tell you what problems of the modern world are solved by blockchain protocols, what problems can be solved, but not yet solved, and where NEAR is in this picture.
Why blockchain protocols are needed
Blockchain protocols provide a very important infrastructure that allows you to run applications that are not controlled by any centralized organization.
In the short term, this is already being used to build financial services that are not controlled by banks and governments. On Ethereum, the most popular decentralized application platform today, a huge number of interesting financial services have appeared over the past two years: MakerDAO has built a decentralized currency whose price is almost exactly one dollar, allowing the use of financial services on the platform using non-volatile assets. Compound built the ability to deposit money into a virtual account and receive an almost guaranteed income, Augur and Flux built services where you can bet on various events in the real world. In addition, a large number of various decentralized exchanges have been launched on Ethereum. All these services are either autonomous and not controlled by anyone, or controlled collectively by service participants.
Financial products that are not controlled by the state and banks is a very important area. But blockchain protocols allow you to do much more.
In the medium to long term, this same infrastructure will enable the building of services and applications that aim to build a free and open Internet and reduce the dominance of oligopolies in our lives. For everyday applications: social networks, chats, interest groups, and others, blockchain protocols allow you to get functionality that is much more difficult to implement without them. Three examples:
1. Single login and general account information. Today, almost all single sign-on services are centralized. If you're using your Gmail account to sign in to apps and Google decides to delete your account, you'll lose access to all the apps you used Google for. Using a blockchain-based solution for a single login allows you not to rely on any centralized organization. Moreover, applications using such a solution can, with the permission of the user, save various information to such a single account, which can then be used in other applications. A hypothetical decentralized Coursera can store the fact of completing a course on the account, and a hypothetical decentralized LinkedIn can show this information, and neither Coursera, nor LinkedIn, nor the login service can delete, change, or close the user's account bypassing predefined transparent protocols.
2. Monetization, assets and microtransactions. One of the reasons why open source service development is not popular is that it is very difficult to monetize them. Since money is a fundamental part of the protocol on the blockchain, and its transfer is not limited in any way, it is much easier to integrate various methods of monetization into applications and services. Without smart ways to monetize, open web work will never attract big, serious teams, and as a result, apps that can compete with the big players won't emerge.
3. Coordination of data storage and calculations. Performing calculations and storing data on blockchain protocols is noticeably more expensive than on the cloud. It is not economically feasible for most applications and services to run on the blockchain. However, if they run and store data on their servers, they can single-handedly shut down their servers and cause data loss, or change the code they run, which is unacceptable in the context of some decentralized applications. Fortunately, there are various approaches that allow you to store data and perform calculations outside the blockchain at a price comparable to the cloud, but do not allow you to delete data or replace calculations. Such approaches use the blockchain as a protocol in which participants providing resources put some collateral as a guarantee of the correctness of their work, and participants using resources can burn or take this collateral if they can provide cryptographic proof that the data was not stored, or the calculations were performed incorrectly.
All of the functionality described above requires the underlying protocol to be reasonably fast, cheap, and understandable to users.
What NEAR decides
NEAR solves two problems that existing protocols have.
The first one is speed, and the resultant transaction price. Ethereum today allows about 15 transactions per second. Demand today is well above 15 transactions per second, and the price of transactions is incredibly high because of this: the simplest transaction today costs about ¢40, more complex ones cost a few dollars. Almost all of the use cases I've described above only make sense if prices are several orders of magnitude lower, which in turn requires much higher bandwidth.
Trying to implement a higher bandwidth protocol while maintaining the requirement that every member of the network validates every transaction and stores all state increases the demands on the hardware. This, in turn, raises the barrier to entry, and reduces the decentralization and reliability of the protocol.
NEAR scales using a different approach called Sharding. I described sharding in detail in the context of blockchains on Habré . Sharding is breadth scaling, and in the long term allows much more computation to be done at a much lower cost than is possible with protocols that scale in height, no matter how high the demands on the hardware.
The second problem is the convenience of use. Developing and deploying applications on NEAR is much easier than on other protocols. And more importantly, users can use applications deployed on NEAR without knowing what a blockchain, transaction, or private key is.
Blockchain protocols are historically designed with the goal of maximum reliability, not user convenience. In many ways, these goals lead to incompatible requirements, and the topic of developing protocols that can be used by people without a technical background, but are reliable enough for scenarios in which the loss of an account can cost millions of dollars, is a topic for a separate article.
For You can see examples of developing applications for NEAR in Rust and AssemblyScript (a subset of TypeScript) in an interactive IDE in the browser, and how they look to the end user.
Instead of a conclusion
The open internet and decentralized financial instruments, by definition, cannot be built by a single company.
Building the infrastructure is a small part of the whole work that needs to be done on the way to an ecosystem in which all basic services are controlled by the community, and not by oligopolies.
If you have ideas for community-driven services that you want to work on, please join our Entrepreneur Support Program .
If you are a developer, join the ecosystem: Let's build an open internet together!
Source: habr.com
