The Aptos Blockchain: Safe, Scalable and Upgradeable Web3 Infrastructure - xiangwan.bit万象

  (中文) 大家好，我是 Aptos 的CTO和联创 Avery Ching，很开心与中国的朋友们见面。

I'm also a 5th generation Chinese American. I studied Chinese in high school. Unfortunately, I am well out of practice as you can see. I'm excited to introduce you all to the Aptos blockchain.
We are the Layer1 blockchain designed for everyone, prioritizing safety, security reliability and upgradability as core priorities. ** **
I've spent over a decade, leading entering teams at Facebook, now called Meta. Most recently as a technical lead of the crypto platform team, which included the companies, Web3 projects in general, blockchain, ecosystem project and most notably the Diem blockchain. My team and I have been working out blockchain infrastructure since 2018, on cutting edge consensus protocols, network storage, paralle execution, programming models and researching a wide breath of technical solutions to help Web3 reach billions. Prior to this, I was the overall tech lead of all Meta's batch processing teams, including Spark graph processing through an open source project I co-created called Apache Giraph. Facebook hoped to do distributed scheduling and unified programming models. These technologies powered the analytics for all the Meta projects and scaled to hundreds of thousands of machines.
I was born in Honolulu Hawaii and completed my undergraduate and Phd studies in Computer Engineering at Northwestern University. My doctoral studies focused on areas of supercomputing, parallel computing frameworks such as MPI and MPIO, and parallelly distributed systems. In short, I'm really passionate about scalable infrastructure. The last 4 years in my life have been focused on blockchains as I believe they are a key enabler from empowering society to govern and managing infrastructure they use as well as the assets within it.
When we think about what enabled the Internet to reach billions of people in so many areas of our lives, including social media, finance, gaming, shopping and streaming services, the answer comes down to three things: intuitive, instant and inexpensive.
We are early in the journey of Web 3 infrastructure. We are in the dialed-out phase of Internet access. All of the existing blockchains combined can't support what a single MySQL server can do today. And consider that companies like Google, Meta and Amazon have hundreds of thousands, if not millions, of MySQL servers to support a single application, such as web search, social media and online shopping.
Web3 will eventually have such applications that reach billions and image the amount of raw hardware required and complex decentralized software working in tandem to support this new world. The cloud infrastructure has been a backbone, scalable and reliable for internet services, data centers worldwide support virtualized and physical servers. Serverless computing analytics and a variety of flexible product pricing models.
This infrastructure has enabled an explosion of internet services for every industry, and startups need to focus on application development, instead of infrastructure scaling. Our industry needs to provide that core decentralized infrastructure layer to do what cloud services have enabled for the Internet. What's even more exciting is that decentralized infrastructure enables applications to interact with each other in a way that centralized services cannot. People can move assets between platforms and transact with different communities without intermediaries. Many of the exciting usecases are yet to be discovered in social, gaming, finance, meeting, entertainment as well as cross-cutting usecases between them. In summary, we believe Web3 applications need to be intuitive, instant and inexpensive. And we need to reimagine the entire blockchain stack to provide the new building blocks and enable new user experience required for large-scale adoption.
Starting off with our core design decisions at AptosLabs, we kind of have to go back 4 years ago. We were thinking about what a blockchain and a Move smart contract language would look like to support billions of people. We came up with Move as a new way to think about how to improve the developer experience, both from a safety aspect and a developer infrastructure experience as well, and onboard as many programmers as possible.
We thought about how we are researching new different types of technology and how that technology could be used in different ways. But we aren't sure exactly what decisions should be made, depending on the use cases there for the future. And therefore, upgradability and configuability will be the most important design decisions that we make sure are baked into the protocol from the very early time.
As far as hardware utilization, we know the validator operators are very concerned about the amount of cost that is necessary to run these machines. And taking the best advantage of their hardware is something important, not to them only, but also to the users and developers in the system. And so we developed a unique modular and pipelined approach to transaction processing. Parallel execution is something that can support high throughput networks. And we think we've developed an interesting technique throughout Block-STM, which allows you to support atomic transactions with high complexity, and yet be able to get extremely high throughput. And finally, in order to reach large-scale applications for Web3, we support different types of sharding solutions, both intra-validator as well as inter-validator.
Went back to intuitive and what that means for user experience. We kind of started on 4 different paths to explore. The first of which is key key management. It's been estimated 10 to 20% of all Bitcoin funds are locked up in unreachable accounts. And This is something that we're really concerned about for user experience. So out of the box, Aptos supports key recovery and key rotation for any accounts. And we've been looking at different ways to support different kinds of stuff that will meet different user needs. For example, today we support a method where a user can actually delegate their key rotation to a third party contract. The third party contract could support hybrid experiences where, for instance, if the user has not transacted onchain for a period of time, that third party can rotate the key on behalf of the user. All this would be transparent. It would be something that is supported by a wallet. And better yet, since it's baked into the L1 there, any wallet can actually take advantage of this feature.
Transaction viability is something else that we thought about from user experience. Typically when you sign a transaction, you kind of make it valid for all time. That's not very safe. And so instead, we think about how we put limits on the transaction viability through expiration times, through sequence numbers, and limiting the damage that's possible when someone signs off on a modification to blockchain.
The third area we focus on is how do we make sure the users are aware of what's going on when they sign a transaction. And so human readable transactions are something that very important to us. We've actually developed a technique where we can simulate transactions onto our blockchain until users exactly what's being modified, what assets are being transferred, what smart contracts are interacting with. And this provides a lot of transparency to know what's happening before you sign your transaction.
Finally, when wallets are interacting with the blockchain, typically, they're just doing so over TLS certificates and kind of trusting the servers at the other end to tell the truth. Light client proofs are a way to kind of secure the last mile security. And combined with a very fine grained timestamp, a granularity of confidence that you're near the tail of the blockchain when you check your data.

Let's talk more about Move. Move is designed as a smart contract language built from the ground up. And when we thought about the things that are important for smart contracts language, it was being deterministic, it is metered execution to make sure there's no doubt service attacks. There's also support resource scarcely in a way where it doesn't rely on programmers, but relies rather than infrastructure itself to support that. And finally, we thought the Move prover would be a very cool tool, which can actually verify application specific semantics without just relying purely on auditing methods. Move supports resource safety. It avoids resource duplication, double spending and unintended destruction. And we know that in Chinese speaking regions, Move actually has a very long history of developments. It's been used in other networks. We've seen lots of developers in those areas developing contracts. There might be hundreds or even possibly thousands of developers in that space. We're really excited about having seen some of the developers come over to Aptos and build on top of our network.
Finally, Move is platform agnostic. It supports different kinds of consensus protocols, different kinds of account models, UTXO and others. It also supports different ways of doing things with a Move adapter which are customized to blockchains itself. And we're really excited about the future of Move and we will take Move in the future as well.
Upgradeability, as I mentioned, is a very key component of the Aptos blockchain. You know, if you almost trade everything except for upgradability and we think we’d be really excited about what we’re building here .And as l mentioned earlier the reason is because we’ve got a long line of research already in the history of blockchains around consensus protocols. And we’re still seeing tons and tons of new development in that space .You can check out, what Rodney and Sasha have done in our with respect to their history of DAG-based protocols and the new things in the future .For example,we also see new programming models coming into play .We have block-STM coming out .These technologies are all not ready today and we want to make sure that we’ll be able to support new things and new ideas in the space quickly to support new usecases that are developed over time.
The way we do this actually is by storing on-chain state within Move. On our blockchain itself, clients can actually sync the state of the blockchain and also to determine exactly what the configurations are and know exactly which consensus protocol to use, what features are now available as well as what to exchange signature schemes, for example, all those things can be done .We build governance to support and facilitate these changes in a decentralized environment .It happens extremely fast and efficiently .This is not something that’s just theoretical, it's something we've done in the past, within the Diem mainnet before multiple times without a hitch.
And we've done actually more recently in our incentized testment. One of the redical changes we had from the original tech stack was the way we think about transaction processing. And the ways of waht we thought that was how do we get the best use of harsware from the validators and how do we enable high throughput ang low latency infrastructure. And the way we drew in for inspiration was from kind of modern day CPU superscalar, superior infrastructure, architectures where you get a high frequency, because you slipt up the transaction processing across many different stages. These stages can be super scalar. And in fact, they can have multiple uses happening in a single stage, multiple computations happening there. I think there's a lot of parallels to draw within our architecture as well. So our transaction processing is split into 500 stages, we have continued transaction dissemination, block ordering parallel execution, back storage and state proof certification. And I'll walk through each of these individually. I think something to note here, though, is that these stages are not dependent on each other, they can operate independently, they can all be paralleled and they can all take advantage of the hardware that's available to them. So in the first phase, continuous transaction dissemination, a validator will continue to send blocks of transactions to other validators and produce what it's called proof of availability when others are willing to kind of certify that they've stored this data and they're not going to remove it.
The next phase is that we take these blocks validator then propose that these blocks be committed with respect to ordering and this is not with respect to transaction themselves. So, a common misnomer is that consensus is slow. In fact, consensus is not slow, it's something agreement. And as long as you don't stuff in other things that don't belong there, such as the transaction dissemination, the execution, the storage, consensus is actually very fast. In this case, we disagree on the metadata. We don't agree on the transactions, the execution of that or any of the things like this happening in parallel as well.
Finally, the next phase is gonna to be going to pallel execution. And at this point, you have an ordering of data, you have the opportunity to actually recorder, as long as validators don't agree about that ordering. But this is simple and for a second, validators are gonna execute transactions in parallel through software transaction memory libraries with optimistic concurrency control using the block-STM as I suggested and this allows us to get extremely high throughput from our network.
Another thing that's great for efficiency is think about batches. And batches are something that we do continue throughout the system. Batching is an efficient optimization for we, think about signatures on batches versus single transactions, when we think about the way we do rights. In this case, you have a global state change by doing this global state change and then writing in bulk, you save on I/O ops, you write larger chunks and get better bandwidth. And kind of overlapping writes are eliminated from the write path completely. Just making much better use of that hardware.
The final phase is, how do we certify proofs. We want to make sure we generate the authenticated data structures around ledger history, and ledger state. This is useful for light clients. This is used for state synchronization and for auditing all kinds of other purposes.
I'd like a chance to talk about the way we do parallel execution which we think is very differentiated from the rest of industry. It's common in most cases where other Parallel runtimes will kind of declare out front your read/write dependencies in order to kind of simplify the process of determining what can be parallelly executed and what cant't be Block-STM doesn't have that restriction. It takes kind of whatever sequential and can still operate and infers that parallelism without programmers assistance. What this means is that for transactions where you kind of don't know exactly what you're writing to, for instance, in auction, we don't know the winner. You actually can do this in a single transaction with block stm whereas with other engines that require that read/ write dependency that has to be split across multiple transactions. So this is something that preserves for programmers and makes it much easier. The way we do this is through an optimistic approach . We use a multi version data structure,look for dependencies and kind of make you when necessary if they're overlaps. But Block-STM also take advantage of other cool techniques, such as reordering as long as we agree on ordering validators to maximize parallel execution or maximize gas fees or maximize whatever we'd like to do.
The way we do this is through an opportunistic approach. We use a multi version data structur, look for dependencies and kind of makes you when necessary if they’re overlaps. But Block-STM also take advantage of other cool techniques like as reordering as long as we agree on ordering of validators to maximize parallel execution or maximize gas fees or maximize whatever we’d like to do. At this point in the processing pipeline.
The final thing l love to touch on, which is coming soon is really our thoughts on sharding. And so when we think about the future Web3 applications need scalable decentralized infrastructure can’t just be a single machine going forward. Any parallel computing environment can scale. Now, the question is where you want to do it externally or internally. We are taking a pretty interesting, unique horizontal scalability while maintaining decentralization. We will be exploring both paths, by the way so making validators that are more powerful or split across multiple machines as well as examining the thought about how do we think about almost like sharding MYSQL. The cool thing is that move can support shards as the fist-class concept. And as l mentioned earlier, Move can be extended to support different kinds of coding paradigms. You can imagine homogenous bridging supports transfer between shards. Or even shards have different kinds of system characteristics shards that are really good for computer. Some are great for caching and some are great for string large amonts of cold storage. And l think the ideas that we want to make them link by a single token, we’re really excited about the community coming together with Aptos.

We started our project in March, aunching our DevNet and inviting developers over to our office hacking with us in May. And just a couple months later, we’ve got more than 200 projects building on, with more than 70+ NFT plan launches, lots of people check out the Github, many people interacting on discord and Twitter. Our testnet traffic actually is pretty high. We see more than 40 transactions per second form users more than 3.5 million transactions day. Some of these projects are so imaginative in terms of being DeFi or NFTs or in social communications. We’re really excited about the folks that are coming together to build together with us. And this is a community fist project and something that we’re excited to see coming together so quickly.
We like to walk through our timeline right now. In mid March, we launch our developer network and have people playing around Move engage form the environment, joining discord all those fun things. In the next couple months, we actually got a chance to work with the community on running incentived Testnet from decentralized startup to staking to governance and upgrades. We’ve been really excited to announce that AT3 is actually completed. And well, the results are coming shortly we do our Mainnet launch in Autumn and as l mentioned earlier upgrades are key to our technology stack. We have a number of different exciting ideas in this space. They want to continue to push out. We experct those to come out every 4 to 6 months. And our goal is to keep the community building on Top of the latest and the greatest technology stack going forward.
In conclusion,we’re really excited about the technology we bring to this space. We care deeply about this market. APEC is an area very core to myself, to mo, to the whole team. And we are gonna be building out a dedicated team within this region to support development and growth. We ask you, please reach out to us. And l hope to meet you all soon. Thank you.
Transcribers：
Xiang Wan, @XiangWeb3
Qi Yi, @qiyixx7171
Lei, @alalei_
From Aptos World, @AptosWorld2