Anoma Research and Development Update: April 2022
April was a month of many social gatherings and inspiring events during Devconnect in Amsterdam, where the second Anoma Huddle was among the highlights. Anoma also co-sponsored the zkSummit and the Gitcoin-organized Schelling Point. Additionally, Anoma founders and team members could be found speaking over a wide range of topics and venues throughout the city. Check out the Community Update article for a more in-depth review of last month’s events, talks and other community focused activities.
As well as a good opportunity to educate new audiences about the possibilities of Anoma, it was also a great chance for teams to sync up in person and lay the groundwork for the next months to come. Hence, this month saw steady progress on many components as we gear up for the first fractal instance of Anoma with Namada.
MASP — Enhancing Privacy Circuits
The multi-asset shielded pool (MASP) is a key component in the structure of Anoma, as it allows for users to create shielded transactions with strong privacy. In the past month, the MASP has been rigorously tested and improved by adding wallet support, human-readable MASP addresses, and encoding of keys.
Also, the MASP validity predicate and MASP parameters loading have been improved, while shielded transaction scanning has been further enhanced by re-using previously scanned context.
Ethereum Bridge — Interoperable Anoma
The Ethereum bridge has also been progressing over the last month, and we now have an initial version of Ethereum state inclusion working in Anoma. Furthermore, the team has been working on designing and implementing the Solidity smart contract, while updating with the new Tendermint ABCI++ version.
The Engineering team also managed to advance the IBC protocol, so it now is able to establish a channel between Anoma and Cosmos Hub (Gaia). They have also been implementing, testing and reviewing the on-chain and off-chain proposal and voting system for governance.
Plonkup & Vamp-IR — Cryptographic Cornerstones
Cryptography has been working especially hard on Plonkup this last month. Lookups have been enabled and successfully tested, Lookup Table traits are being planned as an improvement to the API, and The Circuit/Prove/Verify API has already been greatly improved.
Vamp-IR, a proof system-agnostic intermediate representation that any programming language can target and compile to any circuit backend and constraint system, was presented at ZKSummit during Devconnect in Amsterdam and garnered interest from a multitude of companies.
Watch Joshua Fitzgerald’s presentation “VampIR: universal representation for arithmetic circuits” below.
Furthermore, the MASP improvements have now added the ability to embed only the verifying key in the binary, as well as adding benchmarks, specifications, and other support for the new Convert circuit.
MiniJuvix — A Native Programming Language
MiniJuvix has also been progressing steadily over the past month and is now ready for another release (v0.1.3) on May 5 with new and exciting features included.
The team behind MiniJuvix has especially been addressing questions around polymorphic functions, C-code generation, and compiling blocks to specify inlining of definitions according to backend, as well as having added many improvements for pretty printing and new (global) options to the CLI.
MiniJuvix is mainly inspired by other functional languages like Agda and Idris. It will compile to different backends but mostly cater to Haskell and Alucard.
Typhon-Narwhal-pairing
After consultation with the authors of Narwhal & Tusk, we intend to base Typhon’s Mempool layer on Narwhal, generalizing for heterogeneity (for Chimera Chains). This will allow Typhon to ensure transaction availability (with minimal wasted bandwidth), while keeping transaction storage off the critical path. It will also allow Typhon to scale and maintain high throughput independent of the consensus mechanism. Our teams are now working on generalizing and formalizing Narwhal, and we will ultimately pair the Narwhal formal spec with the Heterogeneous Paxos formal spec.
The structure of Typhon can now be roughly described in terms of layers:
- Clients (or matchmakers) send transactions to Narwhal workers via a public API
- Narwhal workers disseminate transactions to ensure availability
- Narwhal primaries produce block headers based on their workers’ transactions, and produce certificates of availability. Ultimately, this creates a structured DAG of block headers.
- Consensus picks at most one block header per round, establishing a total order of transactions.
- An execution layer (still under development) receives transactions from workers, and ordering from consensus, and allows clients to read the state of the state machine.
Conclusion
It has been a busy and buzzing month indeed, and now we are beyond excited to introduce Namada.
Please subscribe to our YouTube channel to check out our new presentations, to gain an overview of what Anoma is, or to dig deeper into the technology. As always, please follow us on Twitter and sign up for our newsletter for all the latest news.
