"Into the Open Web", China Community AMA.
Conducted by NEAR Protocol Co-Founder Illia Polosukhin and China Lead Amos Zhang.
1、你是如何进入区块链行业又做了NEAR公链的? Hi Illia! How did you enter the blockchain space and come up with the idea of Near Protocol? @illia: Alex and I previously had been working on an AI company NEAR.ai. Though we were doing cutting edge research in the field of program synthesis (automating software engineering), we were lacking real data and real users. As part of our work, we built a crowdsourcing platform that would employ engineers across the world to solve programming tasks to allow us to train better models. We faced multiple issues, starting from payment across the world to the fact that we couldn’t ourselves provide it [the platform] with enough tasks. We started to look at how to make this platform into a marketplace and blockchain seemed like a perfect platform for this. Alex comes from the background of building sharded databases at MemSQL, and I worked at Google Research on large distributed machine learning systems - we went down the rabbit hole of learning about blockchain, consensus and generally surrounding technologies. As we were learning, we stumbled upon the fact that we didn’t find a fitting solution that we would be able to use. Both from a technology standpoint, and even more importantly, from a usability standpoint. We had a chat with some of our friends from MemSQL and Google on July 4th and realized that in that room we had great systems engineers who are all excited about the technology and also have experience building distributed systems. Thus NEAR Protocol was born; we grew the team from the 3 people we had at NEAR.ai to 9 people over a week. Now we have 30+ ppl all over the world. 2、NEAR的分片设计是什么样的,和目前已有的分片方案有什么不同? What is NEAR’s sharding solution, and how will NEAR differentiate with other sharding solutions? @illia: First and foremost NEAR is a developer platform. Meaning that we are focused on delivering the best experience for developers to build applications without limiting the types of experience they can build for their users. This means that we really focused on tooling, APIs, common programming languages and making things really easy to develop. Second, we focused on allowing a common non-crypto user to easily start using applications built on NEAR - you don’t need to have tokens, wallets or prior knowledge of private/public keys to start using things. Sharding and scalability are emerging as the outcome of this - blockchain should not be blocking developers or users from using applications. Hence there should not be limitations on the infrastructure layer. Our sharding is designed to be hidden from the developer. For example, instead of shard chains we shard blocks. This means that developers do not have to be concerned with the shard they are on nor with other applications on that shard and the gas prices among shards. Instead, developers have the convenience of interacting with the NEAR network as they do with a single blockchain now. To achieve that, we have designed a novel sharding approach called Nightshade, you can read more about it https://near.ai/nightshade or check out this video https://www.youtube.com/watch?v=4CKvfYJTjxk. 中文版:https://blog.csdn.net/sun_dsk1/article/details/102763593 还有github版 https://github.com/marco-sundsk/NEAR_DOC_zhcn/blob/master/whitepaper/nightshade_cn.md Additionally, economics is extremely important for any chain, and in sharded or multi-chain setups this becomes even more crucial. We have successfully made strides to both hide complexity and solve some of the burning needs of developers - https://near.ai/economics. 中文版https://blog.csdn.net/sun_dsk1/article/details/102763595 3、你认为分片带来的最大的可用性挑战是什么,NEAR打算如何应对? What are the biggest usability challenges due to sharding, and how do you plan to address them ? @illia: The biggest challenge for developers building on sharded blockchains compared to blockchains like Ethereum is the fact that cross-contract calls become asynchronous. When in Ethereum we send transactions - if something fails mid-way through its execution across many contracts, the system will revert all the changes. This is highly unscalable in nature. And if we look at any distributed system used in Web2, we see that everything is operating asynchronously. You might have seen the DevCon commentary by James Prestwich about how this would hurt the experience and composability. There are a few things we are doing to address this:- Nightshade design makes cross-shard communication to be reliable and execute at the next block produced by the network. Because of this, we removed the need for developers to care when they are calling another contract if it’s in the same shard or not. All cross contract calls get executed in the same block, even if routing across shards have happened.
- Because different contracts might have different usage, it also means different shards might get more or fewer transactions. Dynamic resharding is done every epoch to rebalance the contracts and accounts between shards, and sometimes even change the number of shards, to keep usage of each shard relatively even.
- Economic design (https://near.ai/economics) targets to provide predictable fees for developers and users. That is one of the problems of auction-based systems, that Bitcoin and Ethereum have that the pricing for transactions might be changing dramatically within a short period of time. In NEAR, price is predictably changing from block to block depending on the network usage, which allows developers and users to understand how much will operations cost. Additionally, price is the same across all shards, removing the need for developers to manage that as well.
- Because all cross contract calls are executed in the next block, they are done asynchronously. This is different from the Ethereum model, where calling another contract would be synchronous and return results back into your function. To add developers' ability to operate with it, we have built a promises API that also supports callbacks. We have SDK for Rust and AssemblyScript (TypeScript compiler) that provide API similar to futures in respective libraries. Developers who are familiar with asynchronous programming will be able to pick it up relatively easily. For example, we had a workshop where people not familiar with our tech stack managed to implement a Map-Reduce job across shards.
- Additional tooling is added to make locking safe in a blockchain environment. This is required based compared to a normal state where your program/service is only run by authorized other services, in blockchain anyone can call your contract. This locking mechanics allows developers to write contracts that lock parts of the state within a sequence of cross-contract asynchronous calls and be sure that this lock will be released when the sequence (transaction) will finish. This allows building complex sets of contracts, that operate in a similar way as on Ethereum, propagating errors or reverting changes to the state of other contracts.
- Online IDE to quickly start building: https://near.dev
- Documentation: https://docs.nearprotocol.com
- Rust bindings that also have examples of few contracts: https://github.com/nearprotocol/near-bindgen/tree/master/examples
- Nearlib is JS SDK that allows to build easy frontends / integrate with blockchain - https://github.com/nearprotocol/nearlib
- Example NFT for Corgis - https://github.com/nearprotocol/crypto-corgis-solution
- Went from a small team in San Francisco, to the global community.
- Had changed our sharding design and implemented it, running pre-release TestNet with external validators around the globe.
- Onboarded first batch of application developers who are building exciting apps on NEAR and going to launch with us at MainNet. Helped some of them to raise money and scale up to deliver good experience day 1.
- Had tons of meetups, workshops and 8 hackathons around the world, with developers giving us valuable feedback on how to improve the platform.