Add ZK accounts overview. #169
Conversation
|
|
||
| A sketch of a ZK account protocol is actually surpisingly simple. A ZK account is a special account type in the Celestia state machine that is associated with a _verification key_, which uniquely represents a program whose execution over inputs can be verified. The program is entirely determined by the user, and does not require specific enshrinement in the Celestia state machine. | ||
|
|
||
| Spending from the ZK account (equivalently, advancing the state of the ZK account) is done through a transaction that provides a proof against the current ZK account state. If the proof is correctly verified, the funds of the account are unlocked and spendable as defined in the transaction. Inputs to the proof verifier depend on the specific application of the ZK account (detailed in the following section), which can be defined at account creation time or at transaction sending time. In the simplest form, inputs could be a public key and a nonce—sufficiency of TIA balance would have to be enforced by the Celestia state machine. |
There was a problem hiding this comment.
[no change needed][question for curiosity]
Spending from the ZK account (equivalently, advancing the state of the ZK account) is done through a transaction that provides a proof against the current ZK account state.
Do ZK accounts have the notion of a nonce (a.k.a sequence number)? If not, how do consensus nodes determine which transaction to include if they observe two distinct transactions with valid proofs against the current ZK account state.
There was a problem hiding this comment.
They could, or they could not. This begs the question of who pays the gas for the transaction. It would presumably be from an EOA, sending a message to the ZK account. Should that be clarified here?
There was a problem hiding this comment.
IMO doesn't need to be clarified here b/c this reads well without those details.
No description provided.