Conversation
Clarify the maximum number of blocks per epoch and its impact on latency.
JoshLind
left a comment
JoshLind
left a comment
There was a problem hiding this comment.
Beautiful!! 🚀 Thanks @rex1fernando 😄
| These transactions are public to all validators; this means that the block | ||
| leader may choose to order or censor these transactions based on their | ||
| behavior in a way that is most profitable for them. This phenomenon is | ||
| known as MEV; it has been widely documented and studied in the past several |
There was a problem hiding this comment.
nit: maybe add the full name before the short hand? e.g.,
This phenomenon is known as Maximal Extractable Value (MEV);
| computation, requiring `O(stake weight threshold)` communication per | ||
| encrypted payload. This proposal avoids a similar blowup via a new _batch | ||
| threshold encryption scheme_. Using this scheme, along with heavy | ||
| pipelining, means that the encrypted mempool will support >1000 TPS, with |
There was a problem hiding this comment.
nit: maybe just indicate that the TPS number referenced here is just a start? i.e., we may want to see high numbers in the future? 😄
| pending transactions, and to have the committee decrypt transactions as | ||
| soon as they reach this queue. But this would mean that these transactions | ||
| would wait several rounds after they are confirmed in order to be executed. | ||
| [Rex: should I mention Shutter network by name here?] |
There was a problem hiding this comment.
I imagine this note should be removed? 😄
| security. This is because any encrypted transaction which _targets_ a specific | ||
| block is completely revealed, even _if it fails to be included in the | ||
| block_, for instance because of congestion, or because the fullnode decides | ||
| to censor it. [Rex: should I mention fairblock by name here?] |
There was a problem hiding this comment.
Likewise (remove this note)? 😄
| block_, for instance because of congestion, or because the fullnode decides | ||
| to censor it. [Rex: should I mention fairblock by name here?] | ||
|
|
||
| **Previous batch threshold encryption schemes.** Several previous works [cite] |
There was a problem hiding this comment.
nit: maybe just remove cite if we don't have a reference? 😄
| included in a block and decrypted, the user's transaction intent is | ||
| revealed. | ||
|
|
||
| We must also present this type of payload theft. We do this using the |
| threshold encryption scheme in order to avoid vulnerabilities. | ||
| * to integrate well with account abstraction. | ||
|
|
||
| [Rex: I don't remember why the encrypt->sign design integrates better with |
There was a problem hiding this comment.
Likewise (remove this note)? 😄
| 4. Finally, the `EncryptedPayload::Encrypted` enum variant is initialized | ||
| with the `ciphertext` and the `payload_hash`. This is signed by the | ||
| user's signing key as part of the final transaction being submitted. | ||
| [Rex: explain extra_config?] |
There was a problem hiding this comment.
Likewise (remove this note)? 😄
|
|
||
| Unit tests for each component, smoke tests, forge tests/benchmarks. | ||
|
|
||
| ## Risks and Drawbacks |
There was a problem hiding this comment.
nit: you could maybe just remove this section if there's nothing important to call out 😄
| validators. | ||
|
|
||
|
|
||
| ## Timeline |
There was a problem hiding this comment.
nit: you could also remove this section if you want? Or be more vague (to give us some breathing room), e.g., implementation and mainnet deployment completed in Q2 2026?
2 participants
No description provided.