CIP-0089? | Beacon Tokens & Distributed Dapps

[fallen-icarus]

This CIP proposes a new token standard for efficient aggregation of on-chain data. Using these beacons, it is possible to create all kinds of Dapps that give full delegation control to all users.

---

(Rendered proposal in branch)

[rphair]

@fallen-icarus @zhekson1 some feedback from today's CIP meeting plus some of my own.

One technical review said that this reads like a list of implementation ideas rather than a description of anything that needs to be changed & how it would work... although I was under the impression myself that the provided reference implementations were a map of how it would work.

Can you think of how the proposal could be rewritten that would really make it stand out as a practical CIP, and bridge this gap? (some details below)

[rphair]

I believe it's relevant that the huge community support for at least the non-custodial DEX applications that would be facilitated by Beacon Tokens should be accumulated in:

• definitely the PR discussion
• possibly also as references here in the Motivation section... once we can decide which make the best statements about how / how much the community might need this.

@AntMeyer1 at the CF also offered to help with this, but mainly it's your responsibility as authors to include these references as advocacy for your proposal. So far I've bookmarked (cc @KtorZ):

• https://twitter.com/zhekree/status/1632042865013432323
• CPS-0004? | Spending Script Redundant Execution #418 (review)
• https://matrix.to/#/!QvtUklhUfmEuCBIexz:matrix.org/$lU0OwYOAQXpNYVFJl1I33YPhhQ_wH14Jzu5etQP9Drk?via=matrix.adamantium.online&via=matrix.org&via=forum.balanceanalytics.io

[rphair]

Continuing this request in #418 (review) because it appears to relate to all use cases that might also avail of Beacon Tokens. TL;DR these issues seems so scattered across the DeFi field that someone might have to form a Working Group to clear out a path forward.

[rphair]

These are good reference implementations but they're mentioned like anecdotes instead of a technically explicit process of how the Beacon Tokens are used in each... as CIPs normally have in their Specification section.

@SebastienGllmt mentioned this in the meeting so maybe he could explain more about how this could be done to achieve a more rigorously written proposal.

[zhekson1]

Beacon Tokens are highly generalizable, so we must find a balance in specifying how they should be used; without being overly vague or too specific. To that end, we figure it'd be worthwhile to wait until a few more reference implementations of distributed dApps that use beacon tokens are ready (currently being worked on), so that we can reference them in the CIP, and extract from them a general pattern of Beacon Token usage.
@fallen-icarus

[rphair]

Considering that this may be the most commercially interesting & community supported use case, can you combine it with the 2 above for a list of 3 total? Do they need to be inventoried separately? If not, I think it would be more compelling & readable if all 3 applications were combined in a single section of potential or reference implementations & exactly how Beacon Tokens are used in each of them.

[Crypto2099]

As written and lacking any formal specification, couldn't the processes described in this CIP utilize literally any non-fungible token? e.g. Handles or SpaceBudz? I must agree with @rphair that this reads more like an anecdotal design paradigm for smart contract dApps rather than a "token standard" as merely the presence (or lack thereof) is the only real reference to tokens at all.

[fallen-icarus]

I think people are misunderstanding this CIP which is entirely our fault. Beacon Tokens are a general design pattern, not a specific design. For example, of the PoCs we are working on, the beacon tokens are different for each. For some the beacon tokens are only used for off-chain querying. While others also use the presence/absence of the beacon tokens in the smart contract logic itself. Also some use multiple beacon tokens while others only use one.

It might be better to think of this as a Standard of Standards. Every dApp will have its own beacon token(s). Every user of the dApp must use the same beacon token(s) or else the dApp won't work. The cardano-swaps dex is an example - if multiple beacon tokens are used, the liquidity is fractured over all the beacon tokens. That is why we are calling for dApps to create their own beacon token standard which all users of the dApp must use. This CIP can possibly hold a registry for all dApps and their beacon tokens, hence the Standard of Standards.

This CIP is just meant to show the general pattern. Asking for a formal-specification seems unreasonable since there is only a small piece that will be the same across all dApps: being used for efficient off-chain querying. This piece is already explained in the CIP's Distributed L1 Dapps section. The point of the reference implementations / PoCs is to show particular instances of the general pattern.

The difficulty of explaining Beacon Tokens is similar to explaining Haskell monads. Here is a quote that I think highlights this well:

Monads are very useful in Haskell, but the concept is often difficult to grasp at first. Since monads have so many applications, people often explain them from a particular point of view, which can derail your efforts towards understanding them in their full glory.

[fallen-icarus]

couldn't the processes described in this CIP utilize literally any non-fungible token? e.g. Handles or SpaceBudz?

@Crypto2099 No. The point of beacon tokens is for efficient off-chain querying. Using Handles or SpaceBudz, which can be found in literally any address/UTxO, conveys absolutely no information aside from "this nft is found here". For example, since cardano-swaps' beacon tokens can only ever be found at an address for the DEX, the beacon tokens not only convey "this token is found here" but also "therefore this is a DEX address". In order to use Beacon Tokens properly, they must only be found where they are needed.

Also, beacon tokens are not necessarily NFTs. They can also technically be fungible tokens since there can be more than one of them. You can think of them as address/UTxO labels. All addresses/UTxOs of a particular set get the exact same label. NFT implies that there is only one instance of the label. If there can only ever be one member of a set, like in the address book example, then it would technically be an NFT.

[zhekson1]

As written and lacking any formal specification, couldn't the processes described in this CIP utilize literally any non-fungible token? e.g. Handles or SpaceBudz?

I think it pays to take a step back and understand the purpose of this CIP. As @fallen-icarus mentioned, it is meant as a "Standard of standards" that describes the general design pattern of distributed dApps, which are characterized by bottom-up interactions between user-owned/user-managed script addresses. Although this user-centric design is highly generalizable, all dApps that use this pattern would necessarily have certain technical similarities (such as beacon tokens). Outlining and standardizing these similarities is the sole purpose of this CIP.

For example, though you are technically correct that any NFT can be used as a Beacon, this is practically infeasible. The characteristic feature of Beacons is providing relative context to addresses in a way that is easily queryable. Depending on the dApp, this feature can also be used in combination with token-mediated spending. However, this only works by carefully marrying Beacons' minting policy with scripts' spending policies on a per-dApp basis, which means Beacons have to be dApp-specific (or more generally, spending script-specific).

I must agree with @rphair that this reads more like an anecdotal design paradigm for smart contract dApps rather than a "token standard" as merely the presence (or lack thereof) is the only real reference to tokens at all.

All of this is to say that something as generalizable as distributed dApps may not be formally specify-able, though it is still worthwhile to use the CIP process for the sake of standardization. Perhaps for accuracy it may be better to rename this CIP "Distributed dApps and Beacon Tokens" (rather than the other way around), since the primary use is the former, facilitated by the latter.

[prometheus-pool]

Does this pattern also enable a potential concurrency solution to current dapps that lock funds in a single script address like what people are looking for here input-output-hk/Developer-Experience-working-group#47? Instead of interacting with the dapp script directly, users would signal their intent by locking their funds in their personal script as described by the beacon token pattern. Then anyone could query all users that want to interact with the dapp and bundle them into a single tx, getting the concurrency without a centralized batcher.

[fallen-icarus]

@prometheus-pool Yes, I believe it does.

Instead of interacting with the dapp script directly, users would signal their intent by locking their funds in their personal script as described by the beacon token pattern. Then anyone could query all users that want to interact with the dapp and bundle them into a single tx, getting the concurrency without a centralized batcher.

This is literally how the arbitragers work for cardano-swaps. They are fully decentralized and permissionless thanks to being able to use the beacon tokens. There are still some possible collisions with arbitragers but the collateral is always safe so we get concurrency without risking collateral. The chance of these collisions can be minimized by 1) the arbitragers looking in the mempool before choosing UTxOs to arbitrage and 2) there being more UTxOs available to pick from. Also, there is no loss of determinism like what is being described in the working group.

As another example, one of the PoCs I am working on that uses beacon tokens like this is a distributed DAO. The benefit to this DAO design is that users maintain custody and delegation control of their assets at all times while participating in the DAO. This has (hopefully) obvious PoS security benefits with respect to larger DAOs. If the DAO would like to spend the funds available, it would do exactly as you say: query all available UTxOs (signaled by the presence of a beacon token) and aggregate them into one transaction.

The only problem I have encountered so far with these designs is the redundant executions #418. In short, a Cardano smart contract is executed once for every UTxO consumed from the corresponding address regardless of the logic. To use the DAO example, the DAO in my PoC is just a multisig. All available UTxOs are protected by this shared DAO script. Therefore, it makes logical sense to only execute this script once per transaction no matter how many UTxOs are consumed from the related addresses. Unfortunately, this is currently not possible. If there are 50 DAO members, each with their own UTxO, then that means the DAO script will be executed 50 times, which will likely require several transactions to complete.

Despite this problem, I believe fixing the redundant executions is a much easier task than what is being described in the working group. Here is the solution that I currently intend to pursue. Currently, @michaelpj does not believe the benefits justifies the implementation cost of this approach. Another possible path to pursue would be #309. However, this path does not fix the redundant executions; it just dramatically minimizes the cost of each execution.

What I am hoping to accomplish with this CIP is to show that we should get away from the paradigm of concentrating assets into a single address for using a dApp. There are serious PoS security implications with this design. This CIP is meant to show another possible (IMO better) dApp paradigm that is unique to Cardano.

[rphair]

@fallen-icarus I've reviewed this again after finally absorbing fallen-icarus/cardano-swaps#10 (comment) and am understanding better what is being proposed here & how it would be practically applied.

Other reviewers: I would recommend the above comment as an explanation of Beacon Tokens in terms of a per-dApp tagging vocabulary... @fallen-icarus @zhekson1 I would therefore be happy to see some form of this explanation included in the CIP when it progresses again.

I recently wondered publicly if the Beacon Token could be added as one of the token types in CIP-0068, but now I can see its distinctive feature in the matching logic between the minting and spending scripts, not in the included metadata. @Crypto2099 we both were looking at what made these tokens distinctive (as per #466 (comment)) and I feel like we have a better picture of that now.

[fallen-icarus]

Part of the misunderstanding is my own fault since I am still figuring out how to best articulate this concept.

AFAICT the main difference between CIP-0068 and beacon tokens are the scenarios they were designed to operate in. There are effectively two scenarios:

• Scenario 1: only a single entity can mint a tag for a given use case.
• Scenario 2: anyone can mint a tag for a given use case.

This simple difference results in completely different game theories for each scenario. CIP-0068 was designed for scenario 1 where the business owner (or owners) are the only ones that can mint the reference NFT. Since the business itself depends on the reference NFT being properly used, proper usage is naturally incentivized.

For scenario 2, there is no natural incentive for proper usage of the tag. Consider Cardano-Swaps, a DEX that would be competing with several other DEXs. The value of any activity that occurs through Cardano-Swaps does not go to the other DEX entities. Therefore, the other DEXs have an incentive to destroy Cardano-Swaps in a kind of goldfinger attack. Since anyone can mint a tag, the easiest way to destroy Cardano-Swaps would be to denial-of-service attack it by creating a lot of mis-tagged UTxOs. Then, when users try to interact with each other, there would be too much noise in the query results to find each other.

CIP-0068 does not defend against this kind of attack; it doesn't need to since it operates in scenario 1. Distributed DApps operate in scenario 2 and therefore need more assurances than what CIP-0068 can offer.

[rphair]

@fallen-icarus since my understanding of your related work in Cardano is that Beacon Tokens are required by some peer-to-peer design patterns, I have to assume that you want to pursue this. However we do need to record here in the PR what we are waiting for (for the community's as well as editors' sake) and tag it Waiting for Author.

The general pattern we're testing is that updates every 3 months will avoid a Waiting for Author PR being tagged Abandoned and eventually closed: unless you indicate a time dependency or contingency in the finalisation / review of the CIP. cc @Ryun1 @Crypto2099

[fallen-icarus]

I do still intend to pursue this after I finish my current projects, but I can't commit to any timeline right now. I want to reference the p2p-protocols and the desktop app that incorporates all of them in this CIP.

The biggest impact of this design is that there is actually no such thing as a DApp from the end-user perspective. These protocols just extend the basic wallet functionality for end-users. For example, if Alice wants to create a limit order, the limit order is stored in her own address. Since it is her own address, this limit order UTxO should be considered another one of her personal UTxOs that just requires a few extra things in order to spend it. At a high-level, this means Alice can close the limit order and send its assets to Bob in the same transaction. The desktop app is capable of exactly this so I think having a real world example will help explain the concepts of this CIP.

If it is easier, feel free to close this CIP for now and I can re-open it when I am ready to continue working on it.

[rphair]

no thanks @fallen-icarus - as long as the last notation is specific about what we are waiting for (as you have been) I'm going to try to codify (on the new CIP repo Wiki) that should be enough.

The CIP process could also be evolving (via #883) a Waiting for Project label (currently conceived just for institutional projects like Plutus and Ledger), but could also be applicable to dependent implementations that take work precedence over a related CIP... @Ryun1 @Crypto2099 any thoughts?

p.s. on reflection after today's CIP meeting I think cases where a CIP is waiting on the author(s)' own project that the appropriate tag is still Waiting for Author, to keep the set to tags minimal. It works well as seen in this case because the same comment to avoid tagging it Abandoned (and closing) would also serve to notify readers & editors what we are waiting for.