Specs v2 Master Planning Thread

Protocol Design Specs v2
1

Product requirements (from here):

AnomaV2ProductReqs
AnomaV2ProductReqs1920×1986 214 KB

1 Like
2

Thanks! @apriori was kind enough to go over this in a 10 min 1o1 after the call.

I have one question about the P2P set-up for v2. Will the nodes in the decentralized testnet be run on different IP addresses?

3

Agenda

  • Recap what Anoma v2 is
  • Recap preexisting product requirements
  • Discuss changes / clarifications to Anoma v2
  • Rough planning for specs writing (may save for later)

Topics

  • Research v2 (specs)
  • Engineering implementation
  • Product Development

The basic thesis for Anoma v2 - minimum decentralized Anoma with as real application interfaces as possible.

  • The guiding goal in much of the versioning - most important is the interface between the Node and applications - submitting intents / transactions how do we format them, this is what applications will be written against.

  • Application interface includes - all the resource machine, serialization and merkalization of application data, state query formats, different context addressed compute, status of the transaction, includes some of the very high level p2p interfaces (send, publish, subscribe - apps will do this)

  • Primary way of making decisions of standardize vs specify - everything here is the priority because applications can be built against this interface.

Abstract Spec

Specs should be Consistent + Complete + Diagrammed

  • Specs - point to point and very basic pubsub - p2p with static peering configurations
    • We will have point-to-point connections - do we want forwarding, onion routing /relaying?
    • Relay is not crucial in the first release - can still do basic pubsub without relay
  • Consensus - Byzantine Paxos by refinement with round robbin leader selection ala Tendermint - essentially HPaxos without Heterogeneous part.
  • Resource Machine v2 - part of the app interface
    • Multi-signature PoS - implemented as a RM application but needs a connecter to consensus. Simple multi-signature implemented as RM app, one resource stores or links to voting weights to each pubkey and weights are read each block by HPaxos.
  • Will put some applications in specs - basic Kudos, basic multichat, basic public signal.
    • We need some kind of first draft of coding formats for application state - some may also be used for data structures in the Anoma protocol
    • Are we using Elixer encoding for data encoding for p2p? We are using message pack and serializing it on the Elixer side. We did not merge in yet.
  • Encoding message protocol, send messages to the Anoma node itself - user interaction messages
  • Basic over the air upgrade system - hot code reloading being able to ship updates across the network.
    • Can we just have new git releases (hard security issue will solve later) can we distribute over p2p network and recompile them.
    • Probably should sign these - for v2 we will embed a trusted pubkey (optional config)

Concrete Spec

  • Encoding formats for Anoma protocol data structure
  • Nockma support for transaction candidate evaluation
  • Cairo support for resource logics (this we basically have already)

Overall we have Nockma support, Cairo support we have some work done, just need to merge a PR from @xuyang , this should add in Cairo execution. Xuyang is now writing the compliance circuit in Juvix.

  • We might want RISC-V support
    • We might want to but this in broad subsections
    • suspect each of these things that run RISC-V have specific environments setup - not enough information to make a specific requirement now.

Engineering and implementation

  • Binaries for major platforms, MacOs, Brew, Linux (whatever is easiest), Windows
  • Some amount of internal QA, 90% test coverage, network simulations with real servers talking to each other.
    • want to run in CI but also on local computer spawn up local networks.
  • Basic CLI for these applications
    • already have CLI for the node, is a bit buggy at the moment.
    • Can send messages to your running Anoma node.
    • We have a snapshotting system that can dump to disc and restart. There exists a dump file you can just take and load.

Product / Developers

Run decentralized test-nets

  • For v2 the basic thing we want to be able to do is run a decentralized testnet with hundreds -1000s of p2p nodes, 100s of consensus nodes. We can assume they have reliable networks and if not they can disconnect. Can assume they will be in data centers or someone running it locally on their computer. We can assume reasonably reliably networks will flow churn during the testnet.
  • Support multiple consensi on the same p2p network - we won’t have any controllers here but we should be able to run multiple consensi on a single node.
  • Write applications in Juvix and run them on the resource machine in test-nets, send transactions and read state.
    • Maybe read transaction execution status.
  • Request storage and compute for the network
  • Think about developer experience, tool chains, tutorials and documentation
    • would be good to run through developer workflows

Outstanding Dependencies

  • Network Architecture ART - Draft Monday May 6 (show some major points) - more polished end of May
  • Resource Machine V2 ART - Pessimistic deadline is end of May (don’t expect to get more optimistic)
  • Maybe Kudos ART report?
  • Engine Template (nSpec) - by the end of next week perhaps a version of it

What can go in specs from forum threads? Light weight ART reports

  • Homogenous Paxos
  • Encoding system
  • Basic OTA upgrade
  • PoS application

What exactly do we need to do to give engineering enough detail wrt to implement with Homogenous Paxos? Need to go back into the OG tech report which has a simple transformation for the homogenous version. Need to check if that has any usage of the COQ predicate in it. If it doesn’t we’ll use directly, If it does we’ll look at how to integrate optimizations.

Takeaways

  • Translate this to promise graph tasks
    • work on the highlights in red and sync again when we have drafts of Network architecture and Engine template

Do you know when engineering is going to be blocked after v1? The beginning of the hacker house likely we’ll be blocked. After we get out the next release, next week, there will be one week or two of documenting making videos, then we’ll just be trying to refine and fix things.

4

Yes, nodes in the decentralized testnet will typically have different IP addresses.