Hello everyone!
Yesterday of NEAR, a project that my colleagues and I have been working on for the past two years.
NEAR is a blockchain protocol and platform for decentralized applications, focused on performance and ease of use.
Today, I want to discuss the problems that modern world faces that blockchain protocols can solve, the problems they can address but currently do not, and where NEAR fits into this picture.
Why Blockchain Protocols Matter
Blockchain protocols provide a very important infrastructure that enables the deployment of applications 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 platform today for decentralized applications – a huge number of interesting financial services have emerged over the past two years: MakerDAO has created a decentralized currency whose price is nearly equal to one dollar, allowing the use of financial services on the platform using non-volatile assets. Compound offers the ability to deposit money into a virtual account and earn almost guaranteed income, while Augur and Flux have built services that allow users to bet on various real-world events. Additionally, many different decentralized exchanges have been launched on Ethereum. All these services are either autonomous and not controlled by anyone or collectively governed by the service participants.
Financial products that are not controlled by the government or banks are a very important direction. But blockchain protocols can enable much more.
In the medium and long term, the same infrastructure will enable the development of services and applications aimed at building a free and open internet, reducing the dominant influence of oligopolies in our lives. For everyday applications: social networks, chats, interest groups, and others, blockchain protocols allow for functionality that is much harder to implement without them. Three examples:
1. Unified login and shared account information. Today, almost all unified login services are centralized. If you use a Gmail account to log into applications and Google decides to delete your account, you will lose access to all applications for which you used Google. Using a blockchain-based solution for unified login allows you not to rely on any centralized organization. Moreover, applications using such a solution can store various information on that unified account with the user's permission, which can then be used in other applications. A hypothetical decentralized Coursera could store a record of course completion on the account, while a hypothetical decentralized LinkedIn could display that information, and neither Coursera, nor LinkedIn, nor the login service can delete, change this information, or close the user's account bypassing the predetermined transparent protocols.
2. Monetization, assets, and microtransactions. One reason why the development of open services is unpopular is that they are very difficult to monetize. Since money on the blockchain is a fundamental part of the protocol, and its transfer is not restricted in any way, integrating various monetization methods into applications and services is much easier. Without reasonable paths to monetization, working on an open internet will never attract large, serious teams, and as a result, applications capable of competing with major players will not emerge.
3. Coordination of data storage and computation. Performing computations and storing data on blockchain protocols is significantly more expensive than on the cloud. For most applications and services, operating on the blockchain is economically unfeasible. However, if they are run and store data on their own servers, they can solely shut down their servers, leading to potential data loss, or alter the code they execute, which is unacceptable in the context of some decentralized applications. Fortunately, there are various approaches that allow data storage and computations outside of the blockchain at costs comparable to the cloud, but without allowing data deletion or computation substitution. These approaches use the blockchain as a protocol, where participating resource providers deposit some collateral to guarantee the correctness of their operations, while resource users can burn or claim this collateral if they can provide cryptographic proof that the data was not retained or computations were performed incorrectly.
All the functionality described above requires that the underlying protocol is sufficiently fast, inexpensive, and user-friendly.
What NEAR Solves
NEAR addresses two problems that existing protocols face.
The first is speed, leading to transaction costs. Ethereum currently allows for about 15 transactions per second. The demand today significantly exceeds 15 transactions per second, resulting in incredibly high transaction costs: the simplest transaction costs around ¢40, while more complex ones cost several dollars. Almost all use cases I described above only make sense if costs are lower by several orders of magnitude, which, in turn, requires much higher throughput.
Attempting to implement a protocol with higher throughput while maintaining the requirement that every network participant verifies every transaction and stores all state increases hardware requirements. This, in turn, raises the entry threshold, reducing both decentralization and the 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 horizontal scaling and allows for significantly greater computations to be performed at a much lower cost than is possible on protocols that scale vertically, regardless of their high hardware requirements.
The second issue is usability. Developing and deploying applications on NEAR is much easier than on other protocols. More importantly, users can access applications deployed on NEAR without needing to know what a blockchain, transaction, or private key is.
Blockchain protocols have historically been developed with the aim of maximum reliability rather than user convenience. In many aspects, these goals lead to conflicting requirements, and the topic of developing protocols that can be used by non-technical individuals but are reliable enough for scenarios where losing an account could cost millions of dollars is a subject for a separate article.
At You can view examples of application development for NEAR in Rust and AssemblyScript (a subset of TypeScript) in an interactive IDE in the browser, and how they appear to the end user.
In conclusion
An open internet and decentralized financial tools cannot be built by a single company by definition.
Building infrastructure is just a small part of the entire work that needs to be done to create an ecosystem where all core services are controlled by the community rather than by oligopolies.
If you have ideas for community-managed services and want to work on them, join our entrepreneurship support program. .
If you are a developer, join the ecosystem: , let's build an open internet together!
Source: habr.com
