docs: what is a proposer

[imagobea]

What does this implement/fix? Explain your changes.

Code changes mostly remove unused code from old sdk and optimist/proposer API. Also some name updates in optimist/proposer API.

What is a proposer

Introduction

Nightfall is currently an Optimistic rollup, i.e. an L2 protocol designed to extend the throughput of Ethereum's base layer. They reduce computation on the main Ethereum chain by processing transactions off-chain. Optimistic rollups can offer up to 10-100x improvements in scalability. Optimistic rollups also write transactions to Ethereum as calldata, reducing gas costs for users. [1]

Nightfall Proposer is responsible for transaction aggregation and publishing blocks on Ethereum.

Nightfall current implementation vs PoS

We want to transition from a centralised proposer to a multi-proposer solution.

Current implementation for multi-proposer relies on "round-robin selection". New proposers are stored in a linked list (we store the address of the last proposer added too). From this list, someone will act as currentProposer, being the only proposer able to produce new blocks. After 4 blocks in L1, proposer should be rotated by calling changeCurrentProposer. How this works is not fully defined but the idea would be for each proposer to monitor currentProposer and proactively call the function whenever they go next. Cryptoeconomic incentives are in place to ensure that proposers act honestly. They must deposit a bond upon registration and they will also provide some stake each time they propose a block.

With @daveroga 's PoS PR we will transition into a weighted round-robin, where proposers are selected randomly but can improve their odds by having larger stakes. In this implementation, changeCurrentProposer defines a Proposer set. This set are the selected proposers with calculated weights that will be proposers during the sprints of next span (see image). So calling changeCurrentProposer will update currentProposer to the next one in the set, or will produce a new Proposer set by the end of the span/last sprint. FYI this implementation also drops bonds in favour of stake.

I highly recommend to visit Hackmd to learn how Producer set is generated. You can also deep-dive into the original conversations and see some code on this repo, issue #283 .

As a proposer...

• I can register to join the proposers network. Requirements: a) Optimist running b) need to provide url c) with PoS, also stake - what is the minimum stake? At the very least it has to match SLOT d) is KYC needed? Etc.

• I need to open a web socket to listen to Optimist events. These are: a) "block" - I am currentProposer and I need to propose the next block, b) "blockProposed" - new block added to the chain, c) "rollback" - challenge was successful and block(s) need to be removed. The last 2 are to keep Optimist in sync with the network.

• I can update the URL I set upon registration. With PoS, the ability to add staking has been "tight" to this same function updateProposer in Proposer.sol.

• I can de-register anytime (even if I am currentProposer). After some time, I can also recover my bond/stake.

• I should be "motivated" to monitor/call changeCurrentProposer, so that proposers rotate once the defined period has elapsed

• I can receive off-chain transfer and withdrawal transactions for a fee, which will be added to Optimist mempool. FYI Optimist already prioritises most profitable transactions when assembling a block (getMostProfitableTransactions).

• I can set/update a minimum value for fee, so that I can refuse transfer and withdrawal transactions that I don't consider profitable. Perhaps there is also a MAX_FEE?

• I can earn rewards for each block-proposed which is legit. After some time, I can also claim these rewards.

• I will lose stake for every successful challenge (that is, Challenger identifies malicious behaviour)

As a user...

• I can see who is current proposer
• I can get a list of proposers and their fees
• I can select to whom I send my off-chain transaction
• I can monitor both on-chain and off-chain transactions (Block Explorer will only display mempool for current proposer, but we might consider providing ability of displaying other mempools)
• I should be able to cancel my transaction if this is being ignored

Does this close any currently open issues?

Closes #944

Any relevant logs, error output, etc?

N/a

Any other comments?

References
[1] https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/#transaction-execution-and-aggregation

[signorecello]

Amazing work. This is a great guideline for what comes next in terms of an informed proposer architecture. Thank you @imagobea

[imagobea]

More questions:

• What happens to idle proposers

[luizoamorim]

Proposer Brainstorming

I'm adding some thoughts about proposer fees.

First we need to establish the L2 transaction price in terms of bytes.

We also need to establish a minimum stake to be a proposer.

Then we can start the fee calculation from this minimum stake to a maximum fee. How?

• I.e: a minimum stake to be a proposer is 10 MATIC. For this minimum the fee is 1 * (transaction bytes * transaction price by bytes)
• Then if the proposer increase the stake to 20 MATIC, now the fee go to 1.1 * (transaction bytes * transaction price by bytes)

Now we can think in a way of the user choose with what proposer in the proposer set it want to do a transaction.

Let’s say that the proposer set is

• Alice: 50 Matic
• Bob: 20 Matic
• Clara: 20 Matic

And the proposer set is [ Alice, Alice, Alice, Bob, Clara ] - I think here we can order by the big stake to the less.

So the user can choose one of the prices in the proposer set to pay:

1.1 * (transaction bytes * transaction price by bytes) to Bob or Clara (The user will wait more to have the transaction added to the block)

1.4 * (transaction bytes * transaction price by bytes) to Alice (The user will have the transaction added first)