Hey and welcome to the second part of my article about Zeeka Network!

In my first part of the article about Zeek Network, we get acquainted with first-level blockchains, their problems, second-level blockchains, in particular ZKP and what problems they solve.

In the second part of the article, I will describe how the Zeeka Network works!

The main chain will use Monero's excellent RandomX hash function to implement Proof-of-Work consensus. One can contribute to the Zeeka Network in one of two ways: by offering consensus or by carrying out contracts and demonstrating their execution. While Executors execute zkSNARK contracts and supply the proofs, Miners contribute to the consensus. The contracts are not required to be executed by the Validators, who instead use the Executors' proofs to determine whether state transitions are valid. There are two ways that users can contribute to the Zeeka Network: either by offering consensus or by executing contracts and displaying their execution. While Miners contribute to the consensus, Executors carry out zkSNARK contracts and provide the proofs. The Validators are not required to execute the contracts and instead judge the validity of state transitions based on the Executors' proofs.

Executors of transactions are the core of the Zeeka Network. They will be responsible for the state of the blockchain and user operations.The Ethereum blockchain's Transaction Executors are quite similar to zkRollups operators. Since Transaction Executors are a part of the Zeeka blockchain's core and not a different layer-2 approach, Zeeka will be optimized to handle them. Zeeka will discourage regular transactions and require users to join an Executor's payment network in order to conduct financial transactions.

In Zeeka, a Smart Contract's analog is a Zero Contract. It is suggested that contracts on the Zeeka blockchain not be made for a specific virtual machine (such as EVM). It is suggested that the contracts be written in R1CS (the building block of zkSNARK circuits). Anyone can use the R1CS contract's verification keys, which can include many circuits, to change from one state to another with a single transaction after the programmer uploads them to the blockchain (which could be just a compressed version of thousands of transactions). It is suggested that Zeeka's Zero-Knowledge proof protocol serve as a CIS (Common Reference String) that may be used to instantiate various circuits without having to establish a trusted setup each time.

Because they only enforce data availability of the chain history and not the actual SNARK state, VM-based blockchains (like Ethereum) are unable to ensure data availability of the SNARK state. Zeeka nodes and miners operate in a fashion that only accepts chains that include the data from the previous block; specifically, they verify that the data's hash matches the state-hash submitted in the previous block. This method ensures that the last block's compressed state is always accessible. The network rejects a longer subchain with an unavailable tip state because it is worthless. The blockchain used by Zeeka keeps track of state sizes and stops them from growing out of control. If the state's size grows, executors are responsible for paying for more bytes.

The Main Payment Network contract will be posted in addition to the user-developed contracts already present on the Zeeka Network. The Main Payment Network will be a sizable zkSNARK-based payment network that inherits the main blockchain's consensus and data availability guarantees. All Zeeka wallets will primarily use this network as a means of payment and only submit standard transactions when they want to take money out of one contract and put it into another.

I appreciate you reading this content. I hope that you now have a clearer grasp of how Zeeka Network will operate. The third post will discuss the Zeeka development team, token economics, and road map.

Keep tuned!

Hey and welcome to the second part of my article about Zeeka Network!

In my first part of the article about Zeek Network, we get acquainted with first-level blockchains, their problems, second-level blockchains, in particular ZKP and what problems they solve.

In the second part of the article, I will describe how the Zeeka Network works!

The main chain will use Monero's excellent RandomX hash function to implement Proof-of-Work consensus. One can contribute to the Zeeka Network in one of two ways: by offering consensus or by carrying out contracts and demonstrating their execution. While Executors execute zkSNARK contracts and supply the proofs, Miners contribute to the consensus. The contracts are not required to be executed by the Validators, who instead use the Executors' proofs to determine whether state transitions are valid. There are two ways that users can contribute to the Zeeka Network: either by offering consensus or by executing contracts and displaying their execution. While Miners contribute to the consensus, Executors carry out zkSNARK contracts and provide the proofs. The Validators are not required to execute the contracts and instead judge the validity of state transitions based on the Executors' proofs.

Executors of transactions are the core of the Zeeka Network. They will be responsible for the state of the blockchain and user operations.The Ethereum blockchain's Transaction Executors are quite similar to zkRollups operators. Since Transaction Executors are a part of the Zeeka blockchain's core and not a different layer-2 approach, Zeeka will be optimized to handle them. Zeeka will discourage regular transactions and require users to join an Executor's payment network in order to conduct financial transactions.

In Zeeka, a Smart Contract's analog is a Zero Contract. It is suggested that contracts on the Zeeka blockchain not be made for a specific virtual machine (such as EVM). It is suggested that the contracts be written in R1CS (the building block of zkSNARK circuits). Anyone can use the R1CS contract's verification keys, which can include many circuits, to change from one state to another with a single transaction after the programmer uploads them to the blockchain (which could be just a compressed version of thousands of transactions). It is suggested that Zeeka's Zero-Knowledge proof protocol serve as a CIS (Common Reference String) that may be used to instantiate various circuits without having to establish a trusted setup each time.

Because they only enforce data availability of the chain history and not the actual SNARK state, VM-based blockchains (like Ethereum) are unable to ensure data availability of the SNARK state. Zeeka nodes and miners operate in a fashion that only accepts chains that include the data from the previous block; specifically, they verify that the data's hash matches the state-hash submitted in the previous block. This method ensures that the last block's compressed state is always accessible. The network rejects a longer subchain with an unavailable tip state because it is worthless. The blockchain used by Zeeka keeps track of state sizes and stops them from growing out of control. If the state's size grows, executors are responsible for paying for more bytes.

The Main Payment Network contract will be posted in addition to the user-developed contracts already present on the Zeeka Network. The Main Payment Network will be a sizable zkSNARK-based payment network that inherits the main blockchain's consensus and data availability guarantees. All Zeeka wallets will primarily use this network as a means of payment and only submit standard transactions when they want to take money out of one contract and put it into another.

I appreciate you reading this content. I hope that you now have a clearer grasp of how Zeeka Network will operate. The third post will discuss the Zeeka development team, token economics, and road map.

Keep tuned!