Cannon Memory Merklization R&D Instrumentation of FPVM: Create a strategy for measuring the costs incurred by the memory merkle data structure for both cache invalidation and memory merklization when running the op-program. See open issue This may include contributing the fp-tests framework if appropriate Survey and Implementation of alternative constructions: Refactor Cannon to allow modular switching of memory merklization strategy Assess alternative Merkle data structures. This may include, but is not limited to Truncated hexary radix trie (see Howitzer implementation)

In a sentence, what are you going to build?* RollApp Shielded Pool (RSP) is a module that will make it easy for developers to add a multi-asset shielded pool to their Cartesi applications and give users access to private transactions. Please describe in more depth here* As shown by CarteZcash, the predecessor to this project, Cartesi serves as an excellent vehicle to bring privacy features to Ethereum. While CarteZcash allowed for shielding Eth transactions, CSP expands upon this to support any asset (including NFTs) and swapping between assets without leaving the shielded pool. CSP is designed as a service that other rollApps can install in their Cartesi machine. For example a game or DeFi project building on Cartesi could use CSP for managing funds and thus ensure all user transactions are private. CSP could be considered as a private multi-currency bank account plugin for apps. It could also be run by itself in a rollApp to provide a simple transaction rollup similar to CarteZcash. Following the example of the rollApp API we propose an HTTP interface for CSP to allow simple integration from apps written in any language.

Project Name: Delorean Protocol Proposal Category: Research & protocols Individual or Entity Name: ChainSafe Systems Proposer: willemolding Project Repo(s) https://github.com/ChainSafe/Delorean-Protocol

Project Noir Library for PLUME PLUME is an emerging standard for anonymous nullifiers that is compatible with existing Ethereum keys and hardware wallets. This has numerous applications in anonymous voting, airdrops and other applications. The design of PLUME ensures all operations that require a private key can be performed out-of-circuit in a secure element such as a hardware wallet. The client side operations have been implemented for different wallets^3. This application is to implement the PLUME verification circuit in Noir for the secp256k1 curve that maintains compatibility with existing Ethereum keypairs and the existing PLUME client side library. PLUME is parameterized by the choice of curve and hash function. This will be reflected in the implementation using traits and generics in Noir.

Project KZG Proof Verification Library (EIP-4844 compliant) Verifying data contained within an Ethereum blob requires verifying a KZG proof that the polynomial committed to by the blob opens to a given value(s) at a given point(s). The delivery of this project is two Noir libraries. One for efficient pairing checks for the BLS12-381 curve and another that uses this library to perform KZG multi-proof verification. This unlocks the ability to perform verifiable computations over Ethereum blob data within Aztec as well as any other applications that require verification of KZG commitments. The library will be delivered at a standard that is ready to proceed to an external audit including complete test coverage. The public interface of the BLS12-381 pairing library will be the function and associated types to compute fn pairing(p: G1, q: G2) -> Fp12; Recent research by Geometry Research and Alpen Labs^1 has shown a number of different strategies that can be deployed to improve the efficiency of proving/verifying pairing checks and these will be considered for implementation as part of this engagement where possible.

 One Sentence Delorean is a protocol for programmable key distribution. It lets developers write contracts to determine when keys should be released, and to whom. Capabilities Programmability Using Delorean you can write a contract encoding your key release conditions and then encrypt data with respect to a deployed instance of that contract. The contract is responsible for calling a function to notify the validators of the chain they must perform a signing action. The signing action can produce a public decryption key or produce a decryption key which itself is encrypted with respect to a particular users key. This allows for programmatically generating either public decryption keys or decryption keys for a particular individual.

If you are reading this it means you are going to be one of the first people to use the public alpha testnet of the CarteZcash network. Congrats! Please submit any issues you experience here - https://github.com/willemolding/CarteZcash/issues Send any questions or comments to me on Discord (.wollum) Things are going to be quite janky at first and the network might go down periodically and be redeployed. If that happens you will need to delete your local wallet file and produce a new one or it will error. 0. Prerequisites Have Rust and Cargo installedThis is needed to build and install the CLI wallet

This guide was incredibly valuable while figureing this out http://blog.timhutt.co.uk/std-embedded-rust/index.html The goal was to get a version of ethereum-spec.rs to build for an embeded target with no existing standard library or OS syscalls. This must be able to deserialize SSZ encoded Ethereum containers (e.g. state, blocks), do BLS signature verification and compute state transitions. Issues This was a huge pain with lots of little puzzles to solve. I'll try and document them as best as I can Adding #![no_std] to a crate only prevents the crate itself from using std. It doesn't enforce anything about the dependencies so unless every dependency (and their dependencies etc) also doesn't use std it is going to leak in somewhere so we are going to have to build it When building for a non-whitelisted target (e.g not Wasm, windows, mac, linux) then using the std crate requires the #![feature(restricted_std)] crate attribute. This adds a few annoyances:We now need to use nightly rust This needs to be set for every crate that is still using std, not just the root crate. This is a real killer since it means we need to patch any remaing crate that uses std (not just alloc, or core) features.

For the hackathon at EthBogota the ChainSafe team developed a new bridge prototype we called Zipline. Like all great hackathon entries it is a bit of a Frankenstein. Inspired by the work on ZK bridges by Succinct Labs^1, it uses the fault proof code from Optimism Cannon^2 and the Eth2 light client code from Snowbridge^3 to build a trustless block header relay for Gasper based chains (e.g. Ethereum and Gnosis Chain) to EVM chains. The logic is fairly straightforward. The Altair hard-fork adds a light-client protocol to the beacon chain that allows resource contrained devices to trustlessly follow along with minimal communication and computational effort. Even this lightweight protocol is too expensive to execute within an EVM runtime and so we use fault proofs to allow off-chain execution of the light client protocol with on-chain settlement. In the final Zipline protocol anyone can submit sync updates along with a sizeable bond. These updates have a challenge period during which anyone can dispute their validity and trigger the dispute resolution game (by also submitting a bond). This game uses bisection of the execution trace to resolve the instruction where fraud may have taken place. The isolated intruction is executed by the chain as the final judgement for if there was fraud or not. It works exactly like fault-proof based rollups (e.g. Optimism, Arbitrum) but instead of executing transactions it is validating the light-client protocol of another chain.

Background Ethereum Light Client Protocol Since the Altair upgrade Ethereum has a light client protocol that allows a node to follow the network by receiving a single signed update message every ~27 hours. Each sync period (~27 hours) a sync committee of 512 validators is selected. They attest all finalized blocks for their duration and at the end of the sync period a new committee is deterministically selected. A light client node receives SyncUpdate messages which contain: Aggregte BLS signature and participation bitfield Header of the attested block List of pubkeys of next committee Proof committee rotation

A system by which parties can prove they have found some inputs which result in some output for an arbitrary problem and claim a bounty. The problem is defined as a program which compiles to MIPS and reads/writes to particular memory locations for the input and solution. The program can be very large. Only the cost of a challenge increases with problem size (and even then it only increases logarithmically) Applications Bounties could be posted on-chain for the following types of problems Challenging non-convex optimization problems Finding new CDMA/error correction codes or large primes

Smart contracts in Rust All contracts need to begin with the following imports #![no_std] #![no_main] #![allow(unused_attributes)] imports!(); The imports!() macro comes from the elrond-wasm crate and automatically imports everything you need. It includes the following

St Francis FLC https://www.facebook.com/StFrancisFLC/posts/1124215147933062