HackMD
Multi Asset Shielded Pool used in Namada
-
-
MASP is mainly for asset having low txn volume
-
Namada uses MASP for providing multi asset shielded pool
-
Using IBC to send the one token from Namada's shielded set to another chain and then swap in another chain and then IBC again to Namada
-
but here you can instruct validator set in Namada to perform another operation on your behalf on other chain and then come back. So tokens are getting swapped inside the shielded set.
-
MASP
-
contains a merkle tree for each asset and and the leaves of the merkle tree contains the notes of the (value, address, asset_type)
-
using one circuit for multiple for checking all the value spent and value created is very diffucutl so what we do is have circuit for attaching the note to a homomorphic value committment.
-
-
we use pederson committments to ensure this. For one token we do it like this:
-
for multiple assets we choose a V based token a unique identifier
-
Creating new assets on Namada
- we add a new value committment when adding new assets
- when adding new assets we add to the left and in removing to rigt of the eq.
- currently the bridge is public ex IBC
- Namada is an upcoming Layer-1 (L1) developed by Heliax aiming to provide a single privacy pool shared across all assets and networks.
- Namada’s technical innovations include the Multi-Asset Shielded Pool (MASP) and the Convert Circuit (CC). The MASP offers a unified, asset-agnostic privacy set and the Convert Circuit enables programmable asset conversions (e.g., distributing yield).
- Cubic PoS gets its name from Namada’s penalties mechanism. Instead of slashing validators linearly, Namada is implementing cubic slashing. The percentage of stake slashed is proportional to the cube of total stake (whether from one or many validators) that misbehaved at the same time. Once 33% of stake misbehaves, 100% of that stake is slashed.
-
In a more mature stage of the Anoma ecosystem, there are multiple sovereign chains (fractal instances) that provide different features (e.g. one provides multi-asset privacy, another works as a settlement layer, another works as a bartering protocol, etc), have different characteristics in the protocol (PoW, PoA, PoS, or any other forms of sybil resistance mechanism), or are localized versions (e.g. a settlement layer operated by validators in Germany, another by validators based in Berlin, and another operated by folks based in Kreuzberg).
-
For illustration, you could configure the validity predicate of your account similarly to how you would configure the security features of an online bank account e.g. limiting transfers over a certain value, pre-authorizing transfers every month to a specified recipient, etc. Beyond financial and economic appliances, users could leverage this to express preferences with higher dimensionality, such as dictating that the interactions of this account can only be performed when the cost of carbon is incorporated or that only interactions in zero-knowledge privacy are allowed.
AWA talk
https://www.youtube.com/watch?v=4ttwtSEXUUM
- on chain privacy != end to end privacy
- chain analyst think differently
- when combine off-chain and on chain address we get better result
- with more programmable solutions its easy to de anomananize people
- even in messaging betwwen private chains or pools we get leaked information!
- one solution is private bridges for privacy
- Shielded actions on namada can provide a solution for this
Taiga
-
Side note: Information flow control is arguably a better term than privacy since it encapsulates the notion that users control how their information flows, sometimes revealing it to certain parties of their choice (sometimes only to themselves). No system can work if it’s fully private, that is, if nobody can read the data entered in the system. What is private for some may not be private for others. What is important in a system like Taiga is that its users control their data. However, we’ll use the term privacy in this article for convenience and familiarity.
-
Ethereum uses smart contracts when Taiga uses validity predicates to describe the application logic (learn more about the difference here, page 3)
-
Application VP is the defining structure of an application that contains the application logic. Every time the application state is about to change, the application VP is called to validate the state transition. If the application VP doesn't consider a state transition valid, the state will not be changed.
Resources
- https://medium.com/anomanetwork/an-overview-of-anoma-s-architecture-26b72e8c9be5
- https://messari.io/report/namada-unifying-privacy
- https://www.youtube.com/watch?v=axGJ8HdpSSA
- https://www.youtube.com/watch?v=kEYUXv6gnXk&t=492s
- https://github.com/anoma/masp
For Anoma it's an architecture that is trying to solve these 4 problems with the current blockchain ecosystem @apriori
