Skip to content

Commit

Permalink
docs(website,protocol): add more docs on proposing (#14864)
Browse files Browse the repository at this point in the history
Co-authored-by: Daniel Wang <[email protected]>
  • Loading branch information
dionysuzx and dantaik authored Oct 16, 2023
1 parent 36c5ccd commit 0c389e3
Show file tree
Hide file tree
Showing 2 changed files with 17 additions and 1 deletion.
6 changes: 5 additions & 1 deletion packages/protocol/contracts/L1/libs/LibProposing.sol
Original file line number Diff line number Diff line change
Expand Up @@ -141,16 +141,20 @@ library LibProposing {
// - 1x state.taikoTokenBalances[addr] uint256 could theoretically
// store the whole token supply
unchecked {
// Calculate the time elapsed since the last block was proposed
uint256 blockTime = block.timestamp
- state.blocks[(b.numBlocks - 1) % config.blockRingBufferSize]
.proposedAt;

// Reward only the first proposer in an L1 block. Subsequent
// proposeBlock transactions in the same L1 block will have
// blockTime as 0, and receive no reward
if (blockTime > 0) {
reward = (config.proposerRewardPerSecond * blockTime).min(
config.proposerRewardMax
);

// Reward must be minted
// Reward the proposer
TaikoToken(resolver.resolve("taiko_token", false)).mint(
input.proposer, reward
);
Expand Down
12 changes: 12 additions & 0 deletions packages/website/pages/docs/concepts/proposing.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -41,3 +41,15 @@ The anchor transaction is required to be the first transaction in a Taiko block
1. Persisting `l1Height`, `l1Hash` and `l1SignalRoot` to the storage trie. These values can be used by bridges to validate cross-chain messages.
2. Ensuring that the previous 256 block hashes that are exposed to the EVM are correct.
3. Calculating the EIP-1559 `basefee` which will be used on L2.

## How does the proposer earn Ether

When the block is proposed, the TaikoL1 contract will set some L2 block metadata such as `meta.coinbase`, which is the sender of the proposeBlock() tx. When the L2 client builds the L2 block, it will set the `block.coinbase` to this `meta.coinbase` specified for the block on L1. The validity proof (ZKP) for this block must check that the `block.coinbase` is indeed the `meta.coinbase` recorded on L1.

When the ZKP instance is returned from the `TaikoL1` contract with `getInstance()`, the `evidence.metaHash` for the proposed block is included. This is how the ZKP verifier can check that the L2's `block.coinbase` (and other block-level variables as well) are correctly set to what is specified in the metadata on L1.

## How does the proposer earn TKO

The first proposeBlock tx in the enclosing L1 block will earn the TKO reward. The proposer will receive either the maximum reward (specified in the L1 config), or the reward per second (also specified in the L1 config as well) times the block time, whichever is smaller.

> Note: This is a temporary solution which may change soon, as we see an issue that can arise where the proposer will submit empty blocks to earn the reward. Check the comments in `LibProposing.sol:proposeBlock` for the latest design.

1 comment on commit 0c389e3

@vercel
Copy link

@vercel vercel bot commented on 0c389e3 Oct 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deployment failed with the following error:

Too many requests - try again in 27 seconds (more than 60, code: "api-deployments-flood").

Please sign in to comment.