 Hello, everyone. I'm Jen Xie. I'm the CEO of Cryptape, which is a blockchain start-up based in China. And I was a Ethereum developer in Vitalik's research team. But now I'm fully committed to our own blockchain product named CIDA, which is a permissioned blockchain. And today I want to share with you the most important design, the most important design choice of CIDA and why it makes CIDA unique. And the topic is Scalable Blockchain for Enterprise, which is a scalable solution you can use today. With the advent of Ethereum, we can build decentralized applications very easily on Ethereum. And in Cryptape, we provide all kinds of consultancy services to our customers, including notary crypto assets to settlement supply chain. We build all kinds of prototypes. But the most question we've been asked by our customers is, is the solutions you build for us scale? What if the blockchain application becomes super success, and there are a lot of our users using it? Is the solution can handle that much users? But all of us know blockchain has its own scalability problem. Because in blockchain, we need to replicate the transactions as many copies as the nodes in the network and broadcast the replicates to all the nodes. And all the nodes need to process the same task again, again, and again, and then vote. So no matter how many nodes in the network, the whole network, the throughput of the whole network is the same as a single node. You can increase the network throughput by simply adding nodes into the network. So how do we solve the problem? There are actually two solutions. The hard way is what Ethereum or Vitalik is doing now is scale out by sharding, right? What if we don't replicate each transaction that many times? What if we split transaction into groups and we also split nodes into groups? And each group of nodes only need to process a subgroup of transactions. And each group of nodes only need to maintain a substate of the blockchain. That's what sharding is doing. But sharding is hard. If you listen to Vitalik's talk yesterday, there is a dilemma in the scalability problem. You can reach decentralization, scalability, and security at the same time. So in sharding, the most hard part is security. How can you do it in a safe way? So it's very hard. And Ethereum team is working hard on this. And maybe we don't have it today. The other way or the easier way is scale up, right? If the throughput of the whole network is the same as a single node in the network, what if we just upgrade the node in the network? We can use a workstation, even mainframe, instead of a laptop to run a node. Then the throughput of the whole system will naturally increase, right? That's the solution promoted by some big names in this industry. If it's so good, why don't Ethereum just use this solution? The problems of scale up solution is obvious. If you want to build a very decentralized network, you have to make the cost of running a node very low. If you need a mainframe to run a full node, any individual cannot afford that cost. And you may also need very good network condition for that full node, right? So the cost is very high for a mainframe node. And the other problem is centralization. If the cost is so high, then any individual cannot afford it. Then only people with a lot of money can run a full node in the network. So the solution is not suitable for a public chain. But for Cryptape or for a permissioned blockchain, the context is different, right? The users in the network or enterprises, they cannot afford the cost. And in a permissioned blockchain, we can set a barrier for Enter. So if you want to join to be a validation node, we can ask you to buy some minimum hardware to become a validation node. So scale-up solution can be used in permissioned blockchain. And we have an even better way to do that. How? We don't need a mainframe. That's not the way today. We can use the same technique used by all those internet companies. So in CIDA, we redesigned the architecture of a full node to use microservices. We break the functionalities of a full node into many independent modules. And each module can run as an independent process. All of those processes can run on each process can run on an independent server. So you can use a server cluster to run a full node. That's very different from the full node clients of other blockchains today. Because public blockchain client's goal is to have individual run the full node on their laptop. But for enterprise users, they can afford a cluster, and they have the operators to maintain the cluster. This architecture can fully unleash the resources owned by enterprise users. So in CIDA, we have consensus service, which is in charge of ordering all the transactions received by node. And we have executed to process transactions. We have authentication service, RPC service, and all the microservices exchange messages with each other through a message box. Currently, we use Rabia MQ as the message box between those microservices. So we turn the scale up node, we turn the scale up solution into a scale out solution inside a logical node. What is a logical node? Because in CIDA, a full node is not necessarily a server. So we call it a logical node because it may run on a server cluster. So on the right side is a logical node with many servers inside it. From the other full nodes point of view, it doesn't know if the other full node is running on 10 servers or 100 of servers. So what's the benefit? If we break the functionalities into independent processes, we can do a lot of concurrent and parallel optimizations. For example, in CIDA, we have implemented asynchronous transaction validation and execution. What does it mean? When a full node receives a new block, the new block will be broadcast to executor and all service at the same time. And all an executor service can optimistically pre-compute the new block and validate transactions in the new block. It's a concurrent process. And this change will largely increase the system's efficiency. This is asynchrony in a single block. And we go much farther than that. We separate consensus service and executor service completely. So when the system load is super high and all the transactions cannot be processed in one block time, which is three seconds in CIDA, the execution can last across many blocks. And the state route of the final result will be written back to the block when it's finished, maybe three blocks later. And we also do a lot of parallel optimizations in CIDA. So this is a better picture than previous one. Instead of only one service, we can run many service instances for any of the microservice. We can have three authentication service to validate transaction signatures. We can have three RPC services instances to receive requests from clients. And we can have many executors to run transactions in parallel. So this is a benchmark result of CIDA we did one week ago. We deployed a network with 10 logical nodes on a cloud service. And the throughput of the 10 node network is 15,000 transactions per second. And in comparison, some other blockchain solution or the most popular blockchain solution today can reach only 1,500 transactions per second. So it's a 10 times difference. And we found that the throughput of the whole network will increase proportionally to the ability of a single node in the system. Like the orange bar, we use a 4x large server. And in the blue and red deployment, we use twice powerful hardware. And another interesting thing is we find that the performance of blue deployment is almost the same as red deployment. But the blue one uses a single server for a logical node. But the red one uses three lower grade servers for a single logical node. So the result is very promising. And all of this is just a beginning. We are still pushing very hard to increase the system's throughput to do more parallelism in CIDA. And actually, the microservice architecture is the only cloud-friendly architecture today, cloud-friendly blockchain architecture today, because you can fully utilize the server instances on cloud. You can run many server instances to power a full node. And there are many other interesting designs, and I got not enough time. But well, we have native contract other than EVM contract. In the default CIDA stack, we support EVM contract by default. But you can always rewrite your solidary contract with native code. And our native contracts support solidary ABI, and it provides solidary compatible storage API. So you can use mappings, those data structures in native contract. And a solidary contract can call into native contract naturally without any change. This is an example in Rust. By the way, CIDA is written in Rust. And the beautiful of the scale-up solution is that the solution is orthogonal to all the future scaling solutions, like sharding, plasma, state channel. We can use them together. And I believe even in scalability solution like plasma, the root chain still needs very high performance. Still need to do a lot of things like we did in CIDA to support all those child chains. And this is a typical network of CIDA. So we build this network for enterprise users. Each enterprise user can run a full node, which include many microservices. And their users can get access to the network through their full node. This hybrid model deserves more consideration and more research. And we can build decentralized enterprise application on this network. And if you are interested in CIDA, CIDA is fully open sourced. And you can find this white paper. It's all of its code. And we build Docker image. And we provide some symbol bootstrap documents so you can follow the steps and run a CIDA network and benchmark it. We have many customers. Yeah, this is why we need such high throughput, such high performance. Because our customers include like China Banknote Printing and Minting Company. Their product literally has billions of users, right? Thank you.