Brecht Devos

Results 28 issues of Brecht Devos

### Describe the feature request Currently the proposer and the prover are completely separated. In practice however it's extremely likely block builders already know provers. It's also possible to allow...

category.enhancement
area.protocol
area.tokenomics
status.discussion
stale

### Describe the feature request Three ways that a prover could accurately predict the proof cost for a block 1. The proposes shares the block data with the prover so...

category.enhancement
status.discussion
stale

Imagine a world without `.clone()` or `.expr()` everywhere anytime you want to do something with Expressions. That is a world I want to live in.

enhancement

For now these changes are only to support the upcoming preconfirmation testnet! - Implement https://github.com/taikoxyz/taiko-mono/issues/14793 - Add support for proposer selection mechanisms through `ISequencerRegistry`. Currently the testnet needs some very...

area.protocol
status.stale

Proof aggregation minimizes the onchain costs for proof verification, which is very important for zk proof verfication. Without aggregation the onchain costs would be very expensive, with proof aggregation we...

area.protocol

This EIP proposes adding two precompiles that expose the current block context to the EVM

c-new
t-core
w-ci
e-review
s-draft
e-consensus

goal: - aggregate all proofs so we only need to prove something on L1 every X minutes for highest efficiency, like centralized rollups - different provers submitting proofs out of...

I think the Alethia design gets simpler if the anchor transaction doesn't exist and onchain parts are done through a system call like EIP-4788 (https://eips.ethereum.org/EIPS/eip-4788). Certain logic done in the...