Post Discussion: Anoma Roadmap to Launch

General Research
1

This thread is for discussions pertaining to the Anoma Roadmap to Launch blog post.

1 Like
2

Hi @cwgoes thanks for the Anoma roadmap blogpost, I have two main questions:

‘The basic architectural concept for the initial mainnet version – nicknamed “Resource Plasma” after the concept first described in [RFC] [DRAFT] Anoma as the universal intent machine for Ethereum - Architecture - Ethereum Research – is to primarily leverage existing service providers for ordering, compute, and storage services (often bundled together as “blockchains”, and some “solvers” or “searchers”) and knit these service providers together using the Anoma node and P2P system into a distributed network capable of supporting intent-centric applications built using the resource machine.’

By ‘existing service providers’ do you mean Ethereum L1 validators and L2s sequencers, and therefore there won’t be Anoma validators? If yes, this would be quite different from what was said in this blogpost about Anoma and Namada (Two Tokens, One Community | Blog - Namada):

‘Because of this strong alignment, the Namada community is a subset of the Anoma community, which in the immediate term focuses on data protection, public goods funding, and interoperability. As early members of the Anoma community, they are the ones will pave the way for advanced interoperability through cross-chain intents, more granular data protection through information flow control, and will be experimenting with novel intent-centric applications to solve collective action problems beyond public goods funding – by being the first to interact with the novel intent-centric applications on Anoma.’

‘Namada sets the precedent for a network launch that maximizes decentralization through a community-driven genesis process, where the genesis files, parameters, decision to start the network and launching mainnet is entirely in the hands of the community. As a subset of the Anoma community, this is the best equipped community to launch Anoma in the future.’

‘There is a large overlap in the ecosystem tooling and application development requirements making application builders on Namada the best equipped to tinker and build novel intent-centric applications on Anoma, and Namada central to the Anoma community, focusing on solving data protection, interoperability, and funding public goods.’

The second question is about ‘Mainnet does not include any Anoma-specific token or Anoma-specific consensus – but thanks to the Plasma architecture, this is not necessary for developers and users to build and use real applications with real value.’, if Anoma won’t have a token this means there won’t be PoS or validators, and instead you would get security from Ethereum L1? But how will Anoma get security from Ethereum L1 since currently this is still a research area and no L2 get the full security of Ethereum?

1 Like
3

Thanks for reading!

Not exactly. By “existing service providers” I just mean existing organizations and individuals who run infrastructure, including solvers, storage providers, and validators in the Ethereum ecosystem, Cosmos ecosystem, and other ecosystems – certainly including Namada validators (many of whom also participate in these ecosystems). By running Anoma, these parties would become participants in the Anoma network, some of which would indeed validate transactions, so I think it’d be fair to consider them “Anoma validators” – but the role is a bit different than that of a validator in the Cosmos PoS sense; we haven’t figured out all the right terminology yet. I very much hope that Namada validators participate in these intent networks and I also think that they’d be well-equipped to do so!

Anoma is a protocol and (heterogeneous trust) network – it doesn’t make security choices, those are made by users (and to some extent developers). In the Resource Plasma architecture, users and developers can choose which parties are responsible for storing data, matching intents, and ordering transactions. They might, for example, choose some of the existing Namada validators to perform any or all of these roles. I expect that users and developers may make different choices depending on their preferences, who they trust, and the kind of application interactions in question.

1 Like