Subscribe to cryptonerdcn
Subscribe to cryptonerdcn
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Following our last mention of StarkNet releasing an open-source Sequencer, StarkWare has made another big news: the StarkNet Prover is soon to be open-sourced!
Now, all components of StarkNet have been rewritten and open-sourced in three months, after the open-source of the Cairo language in November last year. Here, we will review the open-source stack of StarkNet.
This is an English version of this article, written by cryptonerdcn @StarknetAstro.
First, let's review the StarkNet architecture mentioned in this article.
A Sequencer is an off-chain server that receives all the transactions, orders, validates, and bundles them into blocks. At the moment there is a single Sequencer in the system and it is controlled by StarkWare. For a Sequencer to validate transactions it has to execute them using the Cairo OS, an alternative to the Ethereum Virtual Machine (VM) for smart contracts written in Cairo.
A Prover is responsible for generating encrypted proof of the validity of the Sequence execution trace. Currently, this work is performed by a single Prover, the "Share Prover" or "SHARP."
A Verifier is on L1 and used to verify the smart contracts generated by Starknet Prover. It will update the state on Ethereum L1 to record if successful.
In the previous article, we mentioned the above three components, this time, in addition to Sequencer and Prover, we will also explain FullNode (Verifier and StarkNet Core are smart contracts on Ethereum so they are not within the scope of discussion).
StarkNet's new Sequencer, Blockifier, was released on January 26, with its node part based on Papyrus and its CairoOS part based on Cairo-rs, both of which will be mentioned below. The previous Sequencer was a closed-source client written in python and controlled only by StarkNet itself. The Python client was slow and had no parallelism in transaction execution, both of which seriously impacted StarkNet's TPS and broke the principle of decentralization.
With the Rust-written Sequencer open-sourced, the most basic benefit is that anyone can compile and run their own Sequencer client. At the same time, according to StarkNet's official data, the performance of the new Sequencer has increased by several times compared to the previous version. Here is the roadmap of Blockifier
Integrate with the existing StarkNet Sequencer by replacing its current transaction-blockifying component, which is written in Python.
Implement optimistic concurrency of transaction execution.
Extend the Blockifier into a full StarkNet sequencer, written in Rust, replacing the one currently in use.
Full Nodes are machines that run the Pathfinder client to keep a record of all the transactions performed in the rollup and to track the current global state of the system. Full Nodes receive this information through a p2p network where changes in the global state and the validity proofs associated with it are shared every time a new block is created. When a new Full Node is set up it is able to reconstruct the history of the roll-up by connecting to an Ethereum node and processing all the L1 transactions associated with StarkNet.
Papyrus, a Rust implementation of a StarkNet full node, was released on January 16th. It will be a part of the new StarkNet Sequencer, greatly improving the TPS of StarkNet. Open-sourcing Papyrus will contribute to the improvement of StarkNet's performance and decentralization.
Cairo OS is a virtual machine (VM) in the Sequencer that executes contracts written in the Cairo language. Cairo-rs is a new open-source Cairo VM developed by the third-party developer team Lambdaclass, which will replace the old CairoVM developed in Python.
What does the open-source Prover mean for StarkNet's architecture? Firstly, it prepares for the decentralization of Prover, and secondly, it improves the TPS of StarkNet. Currently, StarkNet only has an official single Prover called "Share Prover" (SHARP). The reason for the name "Share" is because this Prover is not only responsible for generating proofs for StarkNet, but also for generating proofs for StarkEX (what is StarkEX). This severely affects the TPS of StarkNet and goes against the decentralization principle again.
With the open-source Prover, anyone can compile and run their own Prover. Still, the Prover is still only announced as open-source, and the Git Repo has not yet been released. Due to the characteristics of ZK, the calculations required to generate proofs by the Prover are far more than those executed by the Sequencer. Therefore, according to the official old documents, the Prover may need extremely high configurations (as shown in the picture, a 4-core CPU and 16GB memory can only handle 100 hashes per second).
Cairo 1.0 has also been open-sourced last year. Due to the fact that Cairo Language was written in Rust, the entire official ecosystem of StarkNet can be said to have become a Rust family. Still, Cairo 1.0 is not yet supported by StarkNet, so it can not be used to write smart contracts yet. But according to official news, support for Cairo 1.0 will be implemented within Q1 of 2023.
My Twitter：
Following our last mention of StarkNet releasing an open-source Sequencer, StarkWare has made another big news: the StarkNet Prover is soon to be open-sourced!
Now, all components of StarkNet have been rewritten and open-sourced in three months, after the open-source of the Cairo language in November last year. Here, we will review the open-source stack of StarkNet.
This is an English version of this article, written by cryptonerdcn @StarknetAstro.
First, let's review the StarkNet architecture mentioned in this article.
A Sequencer is an off-chain server that receives all the transactions, orders, validates, and bundles them into blocks. At the moment there is a single Sequencer in the system and it is controlled by StarkWare. For a Sequencer to validate transactions it has to execute them using the Cairo OS, an alternative to the Ethereum Virtual Machine (VM) for smart contracts written in Cairo.
A Prover is responsible for generating encrypted proof of the validity of the Sequence execution trace. Currently, this work is performed by a single Prover, the "Share Prover" or "SHARP."
A Verifier is on L1 and used to verify the smart contracts generated by Starknet Prover. It will update the state on Ethereum L1 to record if successful.
In the previous article, we mentioned the above three components, this time, in addition to Sequencer and Prover, we will also explain FullNode (Verifier and StarkNet Core are smart contracts on Ethereum so they are not within the scope of discussion).
StarkNet's new Sequencer, Blockifier, was released on January 26, with its node part based on Papyrus and its CairoOS part based on Cairo-rs, both of which will be mentioned below. The previous Sequencer was a closed-source client written in python and controlled only by StarkNet itself. The Python client was slow and had no parallelism in transaction execution, both of which seriously impacted StarkNet's TPS and broke the principle of decentralization.
With the Rust-written Sequencer open-sourced, the most basic benefit is that anyone can compile and run their own Sequencer client. At the same time, according to StarkNet's official data, the performance of the new Sequencer has increased by several times compared to the previous version. Here is the roadmap of Blockifier
Integrate with the existing StarkNet Sequencer by replacing its current transaction-blockifying component, which is written in Python.
Implement optimistic concurrency of transaction execution.
Extend the Blockifier into a full StarkNet sequencer, written in Rust, replacing the one currently in use.
Full Nodes are machines that run the Pathfinder client to keep a record of all the transactions performed in the rollup and to track the current global state of the system. Full Nodes receive this information through a p2p network where changes in the global state and the validity proofs associated with it are shared every time a new block is created. When a new Full Node is set up it is able to reconstruct the history of the roll-up by connecting to an Ethereum node and processing all the L1 transactions associated with StarkNet.
Papyrus, a Rust implementation of a StarkNet full node, was released on January 16th. It will be a part of the new StarkNet Sequencer, greatly improving the TPS of StarkNet. Open-sourcing Papyrus will contribute to the improvement of StarkNet's performance and decentralization.
Cairo OS is a virtual machine (VM) in the Sequencer that executes contracts written in the Cairo language. Cairo-rs is a new open-source Cairo VM developed by the third-party developer team Lambdaclass, which will replace the old CairoVM developed in Python.
What does the open-source Prover mean for StarkNet's architecture? Firstly, it prepares for the decentralization of Prover, and secondly, it improves the TPS of StarkNet. Currently, StarkNet only has an official single Prover called "Share Prover" (SHARP). The reason for the name "Share" is because this Prover is not only responsible for generating proofs for StarkNet, but also for generating proofs for StarkEX (what is StarkEX). This severely affects the TPS of StarkNet and goes against the decentralization principle again.
With the open-source Prover, anyone can compile and run their own Prover. Still, the Prover is still only announced as open-source, and the Git Repo has not yet been released. Due to the characteristics of ZK, the calculations required to generate proofs by the Prover are far more than those executed by the Sequencer. Therefore, according to the official old documents, the Prover may need extremely high configurations (as shown in the picture, a 4-core CPU and 16GB memory can only handle 100 hashes per second).
Cairo 1.0 has also been open-sourced last year. Due to the fact that Cairo Language was written in Rust, the entire official ecosystem of StarkNet can be said to have become a Rust family. Still, Cairo 1.0 is not yet supported by StarkNet, so it can not be used to write smart contracts yet. But according to official news, support for Cairo 1.0 will be implemented within Q1 of 2023.
My Twitter：
No activity yet