machine mA() { signal fa, fb, fc; state intial { } state other { copy fc; // fc' <= fc

Zero Knowledge proofs (or ZKP) allow developers to create mathematical proofs that a computation have been executed correctly, while not having to reveal all the data of this computation. What are the applications of ZKP? There are three main areas of application: Privacy: because not all data has to be reveal we can proof computations and facts while preserving privacy or secrecy of some part of the data. Scalability and verified computation: usually to check that a computation has been executed correctly you would need to execute it and check the results are the same. With ZKP you can validate the mathematical proof of the computation, and in some systems this could require less time and space resources than executing the computation itself. Interoperability and trustlessness: because ZKPs are based on mathematical proofs, an organisation or individual can trust a ZKP proof without trusting others. What are ZKP proving systems?

Chiquito is a high-level structured language for implementing zero knowledge proof applications. Chiquito is being implemented in the DSL Working Group of PSE, Ethereum Foundation.       Why is chiquito different from other ZKP DSLs? Most ZKP DSLs are based on writing constraints, witness generation and some abstration for DRY like templates or gadgets.

There are currently two cell managers (abbr. CM) in zkEVM-ce, one in the EVM circuit and other in the Keccak circuit. Issue https://github.com/privacy-scaling-explorations/zkevm-circuits/issues/1203 Commonalities In this context a Cell is a pair (column: Column<Advice>, rotation: int). The cell manager can be queried for cells, and it never returns the same. This way each Cell can be used as a different "signal" in the circuit, with the actual underlaying layout in columns and rows of the signals being transparent for the user. Hence, a cell manager has a method that returns a cell that is always different from previously returned cells. Differeneces

This does not include stuff about new front-ends or back-ends or improvements to the Halo2 backend. Statuses, refer to the status of the specific spec, not it implementation. Status can be: TODO, DRAFT, PROPOSAL, FINAL. [FINAL] Constraint builder typing Constraint struct in the DSL should have a field typing (type is a rust keyword). The value is a enum that should be Unknown, Boolean and AntiBooly. AntiBooly means that when the text of the predicate is true, it returns 0, another number otherwise. Queries and expressions when converted to Constraints should have type Unkown.

Main items: Slogan (something fun):Delicious Ethereum community (in Thailand) Extra spicy Ethereum community (in Thailand) Twitter bio (something more serious): Thailand Ethereum community for students and profesionals. Goal:

Current state Currently a step is defined the following way: ctx.step_type_def(step1, |ctx| { // define internal signals let c = ctx.internal("c") // ... // define internal constraints ctx.constr(eq(a + b, c));

Expression builder Generating expressions with columns is very verbose, we can have a wrap type that wraps around columns and use things that we have currently in the constraint builder and in some expression operators. For example: let eb = ExpressionBuilder::default(meta); let index = Column::from(bytecode_table.index, eb); let value = Column::from(bytecode_table.value, eb); let tag = Column::from(bytecode_table.tag, eb);

by Leo Lara (github.com/leolara | https://app.poap.xyz/scan/leolara.eth) Abstract Slashing is a vital part of the Ethereum PoS consensus layer. Work by several contributors has been done in order to optimize it. Prysm is an implementation of PoS consensus layer node software. During its development it was observed that is not trivial to backfill previous information into the slasher. This is, how to consider attestations and block proposals included in blocks before the chain head after initial sync. Previous work done on Prysm concluded that backfilling during the initial sync would unacceptably slow down initial sync, while doing it afterwards would be very inefficient as aparently would require to reconstruct all past states. Also, it is needed to be done in batches in order to do not impact the general performance of the node. In this proposal it is concluded that to backfill the slasher it is actually not necessary to recreate past states. Any future state to the block data that is being backfilled into the slasher is enough. Additionally a way to throttle the backfilling in Prysm in order to do not impact the node performance is proposed.