Thoughts on the token standard

@808mafia This post (like others you have posted recently) are not productive or helpful to advancement of the ecosystem so I’m closing it down. If you would like to help, you can actually join the token working groups not post trolling comments.

I know it can be seen as harsh, but it’s my role to help the community have a healthy forum for deep discussions.

4 Likes

Typically you would want a DAO to manage whatever service that you are thinking about from a Dapp perspective. This DAO is presumably unique to your Dapp. So how would you form a DAO? Fair launch of a token to manage the DAO would be one way.

How do you get the community rallying around the DAO? Well by building on a already existing platform with re-usable code & minimizing the chance of a “naked” rug pull. Enter SNS.

Ok ; so you buy the koolaid(SNS). How do you get investors. Enter community funds. 1.2 M ICP are already on community funds. Depending how this feature turns out, you should be able to pitch to the community to fund your project.

Sonic and infinityswap are DEXs on IC. I used Sonic to provide liquidity for OGY/WICP pair. The experience was f… awesome; with near zero gas fees (0.001ICP).

1 Like

Cryptographic verifiability of ledgers

Let me (re)start a discussion that is orthogonal to the current topics handled in the working group: Cryptographic verifiability of ledgers on the Internet Computer. In a recent call with @witter, he mentioned that cryptographic verifiability is his prime concern for ledgers. He asked me to bring this up in the Working Group again for a more thorough discussion.

Going through my notes of the Working Group discussions, I saw that @witter has voiced his opinion on the importance of this already in (one of) the first Working Group meetings on May 10 where he has flagged this as his primary concern. In a later meeting, this was coming up again and we discussed this issue within DFINITY and briefly presented the challenges in the follow-up meeting. The outcome was, that it is quite challenging and thus do not want to take any action now, but we did not give the discussion any further attention.

Following up on @witter’s request, let me now bring this up again with this forum post for discussion among the participants of the Working Group. This is indeed a very important topic and full transparency of what has been discussed is important.

The technical discussions in DFINITY are summarized next: Having cryptographic proof of integrity of the ledger can be achieved by having all blocks of the ledger cryptographically signed. Signatures could be obtained through the subnet signatures that are used for state certification. Those are BLS threshold signatures generated after every round for the purpose of state certification where parts of the state are getting certified via Merkle proofs.

The execution of messages by canisters is performed in a highly-optimized concurrent fashion and at the end of each round we obtain a deterministic state in each replica that can be certified via Merkle proofs. However, after the execution of each individual message during the round, we do not have an explicit deterministic state on which certification could act analogous to how it is done currently at the end of the round. Retrofitting execution to accomplish this would be a major task and could increase message execution latency by a constant factor (a factor of 2 or 3 seems realistic).

The essence here is that in theory it is possible to get the ledger blocks cryptographically signed, however, there are many practical obstacles and it would be a huge project in the execution layer that would lead to a significantly increased message execution latency to achieve this.

Hope this explains a bit better what the results of the technical investigations so far on the topic of certified ledger blocks have been. Further comments and ideas by the community on other ways of solving this are of course welcome.

7 Likes

It was a pleasure to have a meeting with dieter and discuss the very in-depth issues of the token standard, this summary is very detailed and appreciated dieter’s work. Currently DFT standard solves the problem of cryptographic proof by a built-in blockchain, DEFI also needs sufficient cryptographic proof to gain the trust of users (this distrust is not due to distrust of IC, it is the lack of cryptographic proof provided to users by DEFI applications)

1 Like

Perhaps can someone explain why we want cryptographic verifiability in a ledger to begin with? Are the security guarantees of the IC insufficient?

Is this more of a UX feature so that users feel that their funds are safe, or is there a legitimate security concern with the current ledger design?

Does this mean that the proof of DeFi and token transactions needs to be implemented at the application level by the developers themselves?

User can not trust a DEFI application if they cannot provide cryptographic proof that does not rely on a third party.
If IC DEFI DAPPs cannot provide cryptographic proof that does not rely on a third party. Who can trust such DEFI DAPPs if there is a risk that the DEFI applications are tampered with by third parties? How can users dare to use these DEFI DAPPs to exchange their assets? This is why I keep insisting on providing cryptographic proofs

1 Like

Regarding SNS, I also told @dieter.sommer about my considerations.
I think SNS is a governance model that is more like a DAO for governance. DAO is great, it is valuable and has its own quadrant of problems that can be solved, but I don’t think it solves, nor is it for the underlying cryptographic proofs needed for Token standards and DEFI.

For example, while DAO can be good for resolution by voting, the underlying cryptographic proof needed for token is a tamper-evident proof, but DAO, very clearly, makes the token [modifiable] regardless of which form of resolution it produces. token underlying tamper-evidence is broken by DAO, so I don’t think DAO can replace token the underlying cryptographic proof.

Finally, to summarize, I think SNS is valuable, but I also think the underlying cryptographic proof of the token standard is very important, and the two are not contradictory or conflicting.

3 Likes

Let me clarify and answer some of the questions that have come up. There are different ways on how we can obtain verifiability of the ledger.

Integrity protected record of transfers:

This can be achieved through different means. The one outlined above ?? is by means of cryptographic signatures issued by the subnet (threshold BLS signatures and Merkle proofs). There is another, simpler, approach of having a “blockchain within a blockchain,” i.e., the blocks of the ledger forming a blockchain. There’s possibly further ways one could achieve integrity protection, but let’s remain with those for the discussion.

According to (second-hand) information, not everybody like the idea of having a blockchain within a blockchain. People in this camp think we should use a conceptually nicer mechanism to protect the integrity of the ledger entries. That’s why the approach based on signatures came up.

DelandLab’s token standard as well as the ledger use the blockchain-within-a-blockchain approach to protect the integrity of the ledger. It works well and gets the job done, but there seems to be critical comments from some sides, that’s why we wanted to have this discussion here openly to get everyone on the same page.

Having an integrity protection mechanism like this in place still does not allow for full verifiability as the ledgers as we do not have the transfer requests of users and canisters available in integrity-protected form. That is, a dishonest developer or DAO governing a ledger can still mount an attack and change token balances without a corresponding transaction, but they cannot change anything in the past any more, but only do transfers without a request at the current point in time and add integrity-protected blocks accordingly. Anything in the past is perfectly integrity protected, however.

Availability of users’ and canisters’ certified transfer requests

Full ex-post verifiability of everything regarding a ledger would require that all user’s transfer requests (ingress messages including the signatures) be retained in addition as well as all transfer requests from other canisters. Such requests from canisters on other subnets could be managed as we could use subnet signatures certified the XNet transfers already, but for requests from canisters on the same subnet it is very hard to obtain certified requests that can be later verified with a signature. This is exactly the same problem as discussed in the previous post. So full ex-post verifiability by including all signed transfer requests by both users and canisters is currently not possible. This is something that we could look at in the future.

Hope that this explains the motivation for this discussion better.

5 Likes

transfer signitures!Tho txn signitures maybe not essential for non-defi DApps, txn signitures are key for defi verifibility. Hope IC researchers came up the best mechanics to resolve it on IC. That means everything for developers and investors

1 Like