-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #53 from worldcoin/chore/docs
Chore/docs
- Loading branch information
Showing
6 changed files
with
85 additions
and
160 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
### Network | ||
World Chain is a [Optimistic Rollup](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) on Ethereum. World Chain functions at the Consensus layer identically to that of Optimism, and other optimistic rollups. But differs at the execution layer in a couple ways. | ||
|
||
In a traditional Optimistic Rollup the _Sequencer_ acts as the sole participant that proposes new blocks. | ||
|
||
On World Chain we have two possible block proposers: | ||
|
||
1. `world-chain-builder` - Custom Ordering Policy | ||
2. _sequencer_ - An `op-geth` client constructing blocks with a canonical ordering policy. | ||
|
||
The `world-chain-builder` is the favored proposer in the network. Meaning if the builder produces a valid block the builders block will always be accepted by the network over the sequencers block. | ||
|
||
The sequencer has two jobs: | ||
|
||
1. Attest to the integrity of the Block Proposed by the Builder. | ||
2. Fallback such that if the builder produces an invalid payload, times out, or otherwise - The chain still moves forward. | ||
|
||
Two proposers on the network sequencing blocks is made possible by utilizing an [engine api](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) proxy server multiplexing engine api calls from the consensus layer to both the _sequencer_, and the builder in parallel. We currently use [rollup-boost](https://github.com/flashbots/rollup-boost/tree/main) for this purpose. | ||
|
||
For a deep dive into rollup-boost checkout the [design spec](https://github.com/ethereum-optimism/design-docs/blob/main/protocol/external-block-production.md). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
# Lifecycle of a PBH Transaction | ||
|
||
The World Chain Builder is a custom block builder for the OP Stack that provides Priority Blockspace for Humans (PBH). PBH enables verified World ID users to execute transactions with top of block priority, enabling a more frictionless user experience. This mechanism is designed to ensure that ordinary users aren’t unfairly disadvantaged by automated systems and greatly mitigates the impact of negative impacts of MEV. PBH also enables future flexibility, allowing for a separate EIP-1559-style fee market mechanism for verified transactions. | ||
|
||
The builder introduces a new [EIP-2718 RLP encoded transaction envelope](https://eips.ethereum.org/EIPS/eip-2718) including the necessary data to verify the transaction was created by a valid World ID user. To get a deeper understanding of PBH, lets walk through the life cycle of a transaction. | ||
|
||
|
||
## Creating a PBH transaction | ||
|
||
The contents of the PBH tx envelope simply consists of an [Ethereum typed transaction ](https://eips.ethereum.org/EIPS/eip-2718) and optional semaphore proof ensuring that the sender is verified World ID user. In order to create a PBH transaction envelope, first generate an [Ethereum transaction](https://ethereum.org/en/developers/docs/transactions/). | ||
|
||
Next, [create a World ID proof](), **setting the `signal` to the transaction hash of the tx you are verifying**, and set the `externalNullifier` to the following schema `vv-mmyyyy-nn` where: | ||
|
||
- **Version Prefix (vv)**: Indicates the version of the external nullifier schema This should be set to `0`. | ||
- **Date (mmyyyy)**: Indicates the current month and year. | ||
- **PBH Nonce (nn)**: A `u16` value used to rate-limit PBH transactions. | ||
|
||
Upon receiving the PBH transaction envelope, the World Chain Builder first validates the inner Ethereum transaction and then verifies the PBH payload. The builder enforces a transaction limit for each verified user that resets every month (eg. 50 txs per month), tracked by the PBH nonce specified in the `externalNullifier`. The user creating the PBH envelope must track which nonces they have used, however nonces can be specified in any order. For example, a user could send a PBH tx envelope with a PBH nonce of `16`, followed by a PBH nonce of `10` and so on. Additional transaction validation will be covered further in a later section. | ||
|
||
Below is a quick look at the `PbhTxEnvelope` in its entirety. | ||
|
||
``` | ||
PbhTxEnvelope = { Tx, PbhPayload } | ||
PbhPayload = { externalNullifier, nullifierHash, root, proof } | ||
``` | ||
- `Tx`: Any valid Ethereum typed transaction. | ||
- `externalNullifier`: String identifier used to ensure the uniqueness and proper sequencing of PBH transactions formatted as: `vv-mmyyyy-nn`. | ||
|
||
- `nullifierHash`: Hash of the identity nullifier and the external nullifier; used to prevent double-signaling. You can read more [about the nullifier and external nullifier here](https://docs.world.org/world-id/further-reading/protocol-internals#external-nullifier). | ||
|
||
- `root`: Root of the [Merkle tree representing the identity set](https://docs.world.org/world-id/further-reading/protocol-internals#signup-sequencer). This is the root used when creating the inclusion proof necessary to create a semaphore ZK proof. | ||
|
||
- `proof`: The semaphore proof verifying that the sender is a member of the identity set. | ||
|
||
|
||
## Sending the transaction to the Builder | ||
|
||
Since the PBH tx envelope is a valid [EIP-2718 Typed Transaction Envelope](https://eips.ethereum.org/EIPS/eip-2718), it can be sent to the builder via the `eth_sendRawTransaction` endpoint, just like any other node that implements the Engine API. | ||
|
||
```bash | ||
curl -X POST \ | ||
-H "Content-Type: application/json" \ | ||
-d "{\"jsonrpc\":\"2.0\",\"method\":\"eth_sendRawTransaction\",\"params\":[\"$PBH_TX_BYTES\"],\"id\":480}" \ | ||
$BUILDER_ENDPOINT | ||
``` | ||
|
||
|
||
|
||
## Transaction Validation | ||
// NOTE: PBH transactions are not gossiped or forwarded to the sequencer. All normal transactions are forwarded though | ||
|
||
|
||
## Transaction Priority and Block Production | ||
|
||
The `world-chain-builder` implements a custom [WorldChainEthApi](https://github.com/worldcoin/world-chain/blob/c44417727fcf510597aaf247dc1e2d8dca03a3b7/world-chain-builder/src/rpc/mod.rs#L52) that allows it to recieve PBH transaction envelopes over RPC through an `eth_sendRawTransaction` request. If a semaphore proof is attached to the transaction the [WorldChainTransactionValidator](https://github.com/worldcoin/world-chain/blob/c44417727fcf510597aaf247dc1e2d8dca03a3b7/world-chain-builder/src/pool/validator.rs#L37) will first validate the integrity of the proof, and if valid insert the transaction into the transaction pool with an associated bool indicating the pooled transaction is human verified. | ||
|
||
The transaction pool implements a custom [ordering policy](https://github.com/worldcoin/world-chain/blob/c44417727fcf510597aaf247dc1e2d8dca03a3b7/world-chain-builder/src/pool/ordering.rs#L10) which guarantees top of block priority for verified human transactions. | ||
|
||
A percentage of the block space is reserved for pbh transactions as defined by `verified_blockspace_capacity`. This value represents the maximum percentage of the block gas limit that will be dedicated to human verified transactions. If the amount of pbh transactions does not meet the threshold of reserved block space then non-verified transactions will fill this reserved block space. `100 - verified_blockspace_capacity` is the percentage of the block space always dedicated to non-verified transactions. | ||
|