Why should I trust tokens launched under SNS?

The fungible token standard is the foundation of any Ecosystem . As far as I know, there are many developers who are doing unnecessary waiting because of the uncertainty of the standard, which is slowly poisoning the IC ecology.

We’ve seen developers ask this question about the NNS ledger before, and I’m going to ask this question to sns and try to give some solutions. The following points comes from my discussions with members of the Cansiter Builder DAO (learn about us).

We’ve also seen some discussion about token standards in the community, but I’m getting tired of BULLSHIT being painless about the implementation details, we should look directly at some core issues:

  • Why do I trust a token contract: IC has no main chain data, how to ensure that status values such as balance status and transaction history are not tampered with? So as to achieve cryptographically verifiable? Cross-container calls are initiated by contracts. How to prevent containers from forging users to initiate transactions?

  • Usability issue: Why should the design of ICP’s ledger container be used in SNS? How can developers use tokens under the token standard without functions such as approve/transferFrom?

Current Challenges of IC Infrastructure

As we all know, there will be a block list in the blockchain structure of Ethereum, and the block contains transactions, which is a relatively classic structure in the blockchain. But IC is completely different, IC has no main chain data.

From the design of the community’s token standards, developers have absorbed the experience of different token standards from Ethereum, such as some very basic things like name, symbol, decimals, totalSupply, as well as balanceOf, allowance, approve, transferFrom, transfer these very basic interfaces. This makes it easier for developers to introduce tokens into the business, otherwise there will be no ecology.

Another very important part is how to make adjustments to suit the characteristics of the IC network. For example, IC does not have a history log. If the developer implements the log by himself, and the smart contract of the IC can be updated, how to ensure that the token transaction is trusted based on cryptography, and the history will not be modified by the attacker?

And the mutual calls between the smart contracts of the IC are initiated by the contract itself. If a token contract interacts with another DeFi contract, the attacker can even initiate a fake transaction to steal value without the user’s signature.

The lack of mainchain data makes it difficult for users to trust a token contract, because it goes against the core value of cryptocurrencies - TrustLess. Unless we rebuild a chain structure that can be easily verified. Under the token standard, structures such as transaction records need to be included.

The asynchronous architecture causes IC to have no traditional atomicity, but this is due to the characteristics of the underlying framework, not the problem that the token standard should solve. Therefore, the atomicity problem of IC should not be considered in the design of the token standard.

But is there a solution to the problem of atomicity? Of course, there are two solutions in the distributed world: distributed transactions and sagas. We think sagas is the better option because it’s not have Intrusiveness for development. Intrusiveness refers to using code to adapt distributed transactions to solve the problem of atomicity, while sagas does not require the developer’s code to pay attention to atomicity itself, and is solved through external process coordination.

SNS may not solve the problem

At present, we have not seen the specific implementation code, but in the forum discussion and understanding of the ICP ledger, we can initially understand the current scheme of SNS:

NNS plans to release a dedicated SNS subnet dedicated to issuing tokens. A subnet can run up to 15 token systems (including governance, ledger, and configuration three contracts), allowing third-party developers to deploy by themselves, which can be regarded as NNS community version. The foundation seems to be preparing to allow developers to issue tokens in the SNS using the ICP ledger contract.

The SNS subnet x33ed can already be seen, and there are currently 34 nodes running, but no container deployment yet. Of course, this subnet and other subnets have the same basic structure.

Because the token contract follows the implementation method of ICP’s ledger. In such ledger contracts of ICP, there are no interfaces such as approve and transferFrom, so they cannot be directly used by other contracts. If the developer uses SNS to launched tokens, he must be forced to create a wrap token contract for their token by themselves and then use it in the dapp, just like using Warped ICP.

Tokens issued through sns may only be used directly for trading in centralized exchanges (black jokes about decentralization). If you want to use this token in swap or dapp, you must use its warp token, and the warp token contract itself must be an ERC20-like token contract, so there are problems such as state tampering.

The addition of SNS instead brings double risks to the token from the SNS network itself and the wrap token contract, which makes the token even more untrustworthy (strictly speaking, it is difficult for us to even trust the ICP ledger). Developers might as well use the ERC20-like standard to issue tokens directly. It confuses me.

Implementing self-certification in cryptography

We don’t want to simply complain, but to make the IC ecosystem develop better, so we try to put forward some ideas for discussion with the community.

The core problem of IC’s token standard is that IC cannot provide a chain data structure like Ethereum to prove that transactions are trusted and signed by users. Therefore, token issuers have no way to provide cryptographic-level proofs to users and developers.

The history of the token can be tampered with when the container is upgraded, attackers can send fake transactions through the upgraded container without the need for user signatures, etc., which brings huge risks.

Looking back at the development history of crypto, cryptography-level self-certification and trustlessness are the foundation of value, otherwise everything is built on quicksand.

Chain proof structure

how to solve this problem? Maybe we can imitate the design of BTC in the token contract and implement a database with a blockchain structure. Through the built-in implementation of a blockchain data structure, the proof of all transaction records of the token standard is completed, and the self-certification is completed through the ledger blockchain.

In the classic bitcoin chain proof structure, the next block will contain the hash of the previous block. Any changes on the chain will change the hashes of all subsequent blocks, thus achieving credible proof of the entire transaction history.

We can add a Trust Machine layer to the token contract. For example, we create a Trust Machine canister and remove its controller. It is only used to store the block height and blockhash of the token, as a three-party certificate canister that cannot be tampered with.

When the contract does not have a Controller and the code is open source, the data can only be stored but not deleted and modified. The trust machine container itself can win the trust of the community and developers. If the blockhash and blockheight of the token are stored in the trust machine contract, the token can achieve cryptographic self-evidence, thereby solving the trust crisis (because there is a three-party depository trust machine that cannot be tampered with).

Time proof

The trust machine needs to provide an additional proof of time. Here you can use the Ledger container of ICP, and you can read the last blockhash and last blockheight of the last block at any time.

In the trust machine, when a token submits the blockhash, the trust machine automatically obtains the blockhash and blockheight of the last block of the current ICP Ledger. This can complete the two-level proof structure of token time and data.

Extra benefits

We are actually building a blockchain trust machine with proof of state in a contract, which is a chain within a chain. If we can assign multiple tokens to the same trust machine contract, can we achieve atomicity of transactions between these tokens? This idea is actually very similar to the EVM project Aurora on NEAR.

Self-description of token

On Ethereum, token information needs to be submitted in many centralized places, which will bring inconsistency. Since IC has built-in storage, it can maintain blockchain updates on the chain, and this design can be integrated into Dfinity. These are considerations at the token’s standard interface level.

Interface design

We should not continue to use the token interface design method of the ICP ledger, otherwise developers can only use the wrapped tokens for transactions, which adds another layer of risk. Based on this, we recommend the following designs:

approve/transferFrom

approve/transferFrom is great for preventing double payments. If there is an interface such as approve/transferFrom, as long as approve a certain quota to the market (for example, if the order is 100 ICP, then approve the quota of 100 ICP to the market), and execute a transferFrom while creating the order. If transferFrom is successful, the creation of the order and the sending of the item to the user are completed, which is simpler for developers.

Nonce

This is not needed anymore. After the blockchain is implemented, the token will get the same tx hash for the same transaction, the same sender, the same amount, and the same timestamp, and will be rejected by the blockchain. Therefore, only a timestamp is required (the nonce parameter in the update method of the original token is removed, and an optional timestamp is used to replace this method is simpler and easier to use), and the client call can avoid repeated transactions and replay attacks.

Data storage

Because there is no main chain data, the container only maintains its own data, so we need to store the transaction history and status of the token, which is easy to understand.

The IC supports the storage built into the container, and this part of the storage can be used to complete the storage of its own records instead of EVM events.

The storage space of a container is divided into 4G memory at runtime and 8G stable memory, but for a token with a large transaction history such as USDT, the storage space of a container is far from enough, and expansion needs to be considered.

Here we propose an idea to record an index mapping in the token. An index inside the token points to the storage of the history through an additional archive container. For example, when there are more than 2,000 historical transaction records, 1,000 records will be migrated to the archived container each time, which can alleviate the storage anxiety of the container where the current token is located. There is 4G of memory in each container, and the index occupies a very limited location. By pointing to the container through the index structure, there is theoretically unlimited storage possibility.

Storage containers are automatically created during automatic expansion, and the first expanded container is created only when the transaction is greater than or equal to a certain number, which can save the developer’s cycle to the greatest extent.

When the token cycles are not enough, there will be obstacles in creating a container. To this end, a fallback strategy can be added. By default, the transaction records are stored in the 4G local container storage. After the cycles are enough, the container will be automatically transferred to archive.

The token implements a metric by default, which can obtain the cycle balance of the token, so each token can be monitored for cycles, so as to get an early warning of insufficient cycles.

All failure scenarios such as archiving failures and auto-scaling failures have undergone rigorous testing to ensure that they work properly in a production environment.

26 Likes

Wow! That’s a lot to take in. Looking forward to the discussions on this topic.

1 Like

Do it! the post is a bit whiny, but the ic gives you the tools to do everything you wrote. i dont agree with half the things you complain about but i think you should implement your vision if you want, theres nothing stoping you. this is not eth, this is not btc, this is a different paradigm. once you implement your vision you will realize why it’s wrong, but by all means please go ahead and do it! it will be a learning opportunity.

2 Likes

The complaint is to get the community’s attention, and I want the community to be upfront about the critical issue of trustless.

We are actually implementing some preliminary code, but we also want to have more discussions with the community, and importantly be able to influence the Foundation R&D team on the design of the SNS ledger.

6 Likes

The community is too slow, and officials don’t pay attention to token standards. Hope to speed things up.

1 Like

Is the IS20 also not ok?

There is a lot here! I tried to read and respond. I’m not sure I agree with many of your points, but they point toward the kind of problem-solving we need and we clearly need more examples of how to build these things today. Hopefully, we will have one very soon. Ultimately I agree that the ecosystem is a bit hamstrung by waiting for the SNS. I’d suggest everyone try to build governance themselves. The more ideas we have the better. And when we do get the SNS you can always switch over.

The fungible token standard is the foundation of any Ecosystem . As far as I know, there are many developers who are doing unnecessary waiting because of the uncertainty of the standard, which is slowly poisoning the IC ecology.

Stop waiting and start building. The NNS ledger works. You can fork it. We did. Our token is live. Just do it. We already have a standard developed by DFINITY and it is securing $2B worth of ICP.

  • Why do I trust a token contract: IC has no main chain data, how to ensure that status values such as balance status and transaction history are not tampered with? So as to achieve cryptographically verifiable? Cross-container calls are initiated by contracts. How to prevent containers from forging users to initiate transactions?

It is up to the canister developer to provide this. All the tools are there. The NNS Ledger provides full history and crypto verifiability. I’m not sure what you mean about “preventing container from forging users” but canisters being able to hold your token is a feature not a bug. That is how you build apps on the IC. A smart contract can hold ETH, why not a canister holding ICP?

Usability issue: Why should the design of ICP’s ledger container be used in SNS? How can developers use tokens under the token standard without functions such as approve/transferFrom?

You don’t need approve/transfer from. You can send/deposit. It is just a different pattern that you have to program into your canister. Make it ledger aware and have the user provide their block ID. This pattern works and once you solve the “what to do if the deposit fails” problem (answer, make your canister ledger aware and look for transactions you need to refund) you are good to go. Don’t trust tokens that aren’t open sourced. Period. Ever.

As we all know, there will be a block list in the blockchain structure of Ethereum, and the block contains transactions, which is a relatively classic structure in the blockchain. But IC is completely different, IC has no main chain data.
The NNS ledger has chaindata that can be accessed via query_blocks and get_blocks on the archive. You can download and recalc the entire chain if you want to.

From the design of the community’s token standards, developers have absorbed the experience of different token standards from Ethereum, such as some very basic things like name, symbol, decimals, totalSupply, as well as balanceOf, allowance, approve, transferFrom, transfer these very basic interfaces. This makes it easier for developers to introduce tokens into the business, otherwise, there will be no ecology.

Approve/Transferfrom is broken in ethereum and can be front run to cause massive problems. Most implementations actually break it and don’t follow the actual standard because of this.

Another very important part is how to make adjustments to suit the characteristics of the IC network. For example, IC does not have a history log. If the developer implements the log by himself, and the smart contract of the IC can be updated, how to ensure that the token transaction is trusted based on cryptography, and the history will not be modified by the attacker?

Use the same paradigm as the NNS ledger and submit your canister to decentralized governance. This is what the SNS is going to try to enable, but there is nothing stopping you from doing it today. We’ve launched a governance canister and will soon have upgradeability integrated with governance so that upgrades can’t happen without a vote.

And the mutual calls between the smart contracts of the IC are initiated by the contract itself. If a token contract interacts with another DeFi contract, the attacker can even initiate a fake transaction to steal value without the user’s signature.

Hogwash and poppycock. Never submit your tokens to a canister that isn’t opensourced and verified. Ever. Period. Don’t use defi contracts that can take your coins.

The lack of mainchain data makes it difficult for users to trust a token contract, because it goes against the core value of cryptocurrencies - TrustLess. Unless we rebuild a chain structure that can be easily verified. Under the token standard, structures such as transaction records need to be included.

Again, the canister builder must create the crypto scheme and deploy in a trustless way. If you do this there is no reason you can’t trust the contract.

The asynchronous architecture causes IC to have no traditional atomicity, but this is due to the characteristics of the underlying framework, not the problem that the token standard should solve. Therefore, the atomicity problem of IC should not be considered in the design of the token standard.

Atomicity is not possible across canisters, but it is possible in a canister. Again, if you deploy an open-source canister with proper governance there is no reason you can’t have atomicity.

But is there a solution to the problem of atomicity? Of course, there are two solutions in the distributed world: distributed transactions and sagas. We think sagas is the better option because it’s not have Intrusiveness for development. Intrusiveness refers to using code to adapt distributed transactions to solve the problem of atomicity, while sagas does not require the developer’s code to pay attention to atomicity itself, and is solved through external process coordination.

These are two solutions that one can follow. Why do people not want to implement them? They are complicated?

SNS may not solve the problem

I agree and people should stop waiting for the SNS and try to build it themselves.

Because the token contract follows the implementation method of ICP’s ledger. In such ledger contracts of ICP, there are no interfaces such as approve and transferFrom, so they cannot be directly used by other contracts. If the developer uses SNS to launched tokens, he must be forced to create a wrap token contract for their token by themselves and then use it in the dapp, just like using Warped ICP.

Characterizing a deposit with a canister as a wrapped token isn’t quite right. Again, never send your token to a canister that isn’t open sourced and that doesn’t track its own transactions and that isn’t subjected to suitable oversight. Ever. Period.

Tokens issued through sns may only be used directly for trading in centralized exchanges (black jokes about decentralization). If you want to use this token in swap or dapp, you must use its warp token, and the warp token contract itself must be an ERC20-like token contract, so there are problems such as state tampering.

This is not true. We are days away from launching an NNS ledger based token on a swap contract. It is being tested and there is not an issue with it. We wrote a transferFrom proxy canister in front of our canister in a couple of days.

The addition of SNS instead brings double risks to the token from the SNS network itself and the wrap token contract, which makes the token even more untrustworthy (strictly speaking, it is difficult for us to even trust the ICP ledger). Developers might as well use the ERC20-like standard to issue tokens directly. It confuses me.

What reasons do you have for not trusting the NNS Ledger?

The core problem of IC’s token standard is that IC cannot provide a chain data structure like Ethereum to prove that transactions are trusted and signed by users. Therefore, token issuers have no way to provide cryptographic-level proofs to users and developers.

The NNS token standard 100% has a blockchain in it and can be verified from genesis.

The history of the token can be tampered with when the container is upgraded, attackers can send fake transactions through the upgraded container without the need for user signatures, etc., which brings huge risks.

Never trust a canister that isn’t subject to community review of its token canister and community upgrade pathways.

how to solve this problem? Maybe we can imitate the design of BTC in the token contract and implement a database with a blockchain structure. Through the built-in implementation of a blockchain data structure, the proof of all transaction records of the token standard is completed, and the self-certification is completed through the ledger blockchain.

We actually have two bounties for this: Bounty - ICDevs.org Bitcoin on the IC Reference Implementation and Bounty - QuickStart Dapp - Actor Model that take different approaches to this problem. They are both worth experimenting with.

In the classic bitcoin chain proof structure, the next block will contain the hash of the previous block. Any changes on the chain will change the hashes of all subsequent blocks, thus achieving credible proof of the entire transaction history.

This happens on the NNS ledger as well.

We can add a Trust Machine layer to the token contract. For example, we create a Trust Machine canister and remove its controller. It is only used to store the block height and blockhash of the token, as a three-party certificate canister that cannot be tampered with.

When the contract does not have a Controller and the code is open source, the data can only be stored but not deleted and modified. The trust machine container itself can win the trust of the community and developers. If the blockhash and blockheight of the token are stored in the trust machine contract, the token can achieve cryptographic self-evidence, thereby solving the trust crisis (because there is a three-party depository trust machine that cannot be tampered with).

This is actually a great idea and could be deployed tomorrow. I don’t know that it fixes upgrade manipulation, but is quite a good idea.

The trust machine needs to provide an additional proof of time. Here you can use the Ledger container of ICP, and you can read the last blockhash and last blockheight of the last block at any time.

In the trust machine, when a token submits the blockhash, the trust machine automatically obtains the blockhash and blockheight of the last block of the current ICP Ledger. This can complete the two-level proof structure of token time and data.

Makes sense

We are actually building a blockchain trust machine with proof of state in a contract, which is a chain within a chain. If we can assign multiple tokens to the same trust machine contract, can we achieve atomicity of transactions between these tokens? This idea is actually very similar to the EVM project Aurora on NEAR.

You could build this in a day and it would be a great idea to do so.

On Ethereum, token information needs to be submitted in many centralized places, which will bring inconsistency. Since IC has built-in storage, it can maintain blockchain updates on the chain, and this design can be integrated into Dfinity. These are considerations at the token’s standard interface level.

I’m not sure what your argument is, but this should be doable today. You can serve token metadata and ledger info from HTTP.

We should not continue to use the token interface design method of the ICP ledger, otherwise developers can only use the wrapped tokens for transactions, which adds another layer of risk. Based on this, we recommend the following designs:

Again…this is not accurate.

approve/transferFrom is great for preventing double payments. If there is an interface such as approve/transferFrom, as long as approve a certain quota to the market (for example, if the order is 100 ICP, then approve the quota of 100 ICP to the market), and execute a transferFrom while creating the order. If transferFrom is successful, the creation of the order and the sending of the item to the user are completed, which is simpler for developers.

We have a 600 line approve/TransferFrom proxy canister that works with a slightly modified NNS ledger. The NNS part is already open-sourced and we’ll have the proxy out soon.

This is not needed anymore. After the blockchain is implemented, the token will get the same tx hash for the same transaction, the same sender, the same amount, and the same timestamp, and will be rejected by the blockchain. Therefore, only a timestamp is required (the nonce parameter in the update method of the original token is removed, and an optional timestamp is used to replace this method is simpler and easier to use), and the client call can avoid repeated transactions and replay attacks.

I’m not sure I follow this point, but yes, you want to avoid replay attacks.

Because there is no main chain data, the container only maintains its own data, so we need to store the transaction history and status of the token, which is easy to understand.

The IC supports the storage built into the container, and this part of the storage can be used to complete the storage of its own records instead of EVM events.

The storage space of a container is divided into 4G memory at runtime and 8G stable memory, but for a token with a large transaction history such as USDT, the storage space of a container is far from enough, and expansion needs to be considered.

Here we propose an idea to record an index mapping in the token. An index inside the token points to the storage of the history through an additional archive container. For example, when there are more than 2,000 historical transaction records, 1,000 records will be migrated to the archived container each time, which can alleviate the storage anxiety of the container where the current token is located. There is 4G of memory in each container, and the index occupies a very limited location. By pointing to the container through the index structure, there is theoretically unlimited storage possibility.

Storage containers are automatically created during automatic expansion, and the first expanded container is created only when the transaction is greater than or equal to a certain number, which can save the developer’s cycle to the greatest extent.

The NNS Ledger already does this with query_blocks.

When the token cycles are not enough, there will be obstacles in creating a container. To this end, a fallback strategy can be added. By default, the transaction records are stored in the 4G local container storage. After the cycles are enough, the container will be automatically transferred to archive.

The token implements a metric by default, which can obtain the cycle balance of the token, so each token can be monitored for cycles, so as to get an early warning of insufficient cycles.

All failure scenarios such as archiving failures and auto-scaling failures have undergone rigorous testing to ensure that they work properly in a production environment.

I’m glad you all are building and trying to solve problems. I don’t know that I agree that all of the problems listed are actually problems, but the more diverse solutions we get the more good ideas we will find.

10 Likes

To play devil’s advocate, is it absolutely necessary to store a token’s entire transaction history from token genesis?

In BTC, we need the entire history in order to validate the current balances, and that validation takes a long time since it starts from the beginning.

Chain key cryptography allows the IC to more generally “throw away” old blocks but also allows replicas to sync to the current state using catch-up packages. Along the same lines, I wonder if we really need to store all transactions for a token from the beginning of time. Who needs that information?

Can individual dapps store what they need instead of relying on a canonical (and massive) transaction log? Or does that come with drawbacks?

2 Likes

Hi all, I am a NNS researcher working on the SNS.

To avoid misunderstandings, I just wanted to clarify that an initial version of all SNS canisters is already completed. As you correctly state, the ledger canister will use the same code as the NNS ledger canister. The governance and root canisters can be found here.

As you can see on our roadmap, we are working on further evolving these canisters and also provide better support for the initialisation and upgrades (see for example this forum post regarding upgrades). So if you would like to use an SNS that is deployed on the SNS subnet and maintained by the Internet Computer as a system function, this is planned for the Carbon milestone. However, you can definitively already look at the canisters’ implementation and start implementing against the APIs! You can even self-deploy an SNS with a governance, ledger, and root canister on an application subnet and try it out!

9 Likes

Hi I’m David, NNS Team Lead also working on SNS

I’d just like to add to what @lara said that we’re looking into the technical details and the possibility of publishing all the blocks and state for the SNS subnetwork. This would require some work namely for tooling necessary to replay the state, of course, but it’s definitely something we’re exploring.

2 Likes

Glad to see you guys are making it work, I’ve used origyn’s tokens.I also think developers shouldn’t wait for SNS, because SNS still follows the ICP ledger design, which doesn’t work well with many current DeFi services. DEVS can deploy token contracts in the application subnet first, and then transfer to SNS when appropriate.

You can read Why should I trust NNS Ledger, seriously?. The transaction information of NNS’s ICP ledger canister is stored in archive conisters, but this conisters do not save the user’s signature and authorization records, the controller of the ledger canister can forge a transaction that has not been initiated by the holder by maliciously upgrading to achieve an attack. ICP Ledger canister has this ability, but we believe it will never happen (because of the decentralization of governance), and the situation is different for the token of early SNS. So the ledger canister design that follows the NNS cannot be cryptographically self-verifiable yet. This is also a point I did not discuss above

It took ICP a long time to push hard for decentralization, which is why we trust NNS, and for early projects, decentralization is not so great that governance often doesn’t work, and some developers will prefer to keep the ability to update the contract to fix bugs and avoid being attacked. The economy of early dapps is very fragile to operate prematurely giving all container controllers to a black hole address or a dao is not a good thing.

As I said before, approve/transferFrom is great for preventing double payments. The point is that it’s easier for developers. We currently focus more on usability, and the design of SNS is not easy for developers to handle. In the current use case, it is clear that more developers choosing WICP. And the method of deposit is not in line with the habits of crypto users. Although their habits are all shaped by ETH DeFi, this transition will take some time, and we obviously need LFG now.

This sounds very useful, hope to test it sooner. But proxy servers actually introduce new risks, why can’t we make it simpler? Maybe we can influence community and foundation to make some better optimizations.

2 Likes

This is great!

If SNS leaves enough room for developers, the ease of use issue can be solved. And the number of nodes in the SNS provides better security for everyone.

But I think the foundation should be more proactive in promoting standards after absorbing community discussions, and determining the only token standard directly through governance. Subsequent iterations of other easier-to-use updates can be promoted on the basis of compatibility with the underlying token standard, and it is up to the developers themselves.

It is more important now to give developers more information. I have been suggesting the developers around me don’t need to wait for SNS and directly issue tokens for their own business. But they are still afraid to go because the tokens they issue cannot be trustless. So the promotion of the foundation will be very important, because we trust the foundation very much.

Ahh…I see what you fear is here. Your trust is in the canister having validated the transaction on the way in and now there is no record of that signature other than the artifact of history left behind. Motoko does not have access to this signature and trusts that the nodes verify it(I’m not sure about rust). Every time I suggest we get access to data like this I’m told that they want to abstract away the workings of the block chain. I wish we could do msg.signature and include that data in the block. I’ll add that to the token standard document! Great point. @claudio Have you all considered exposing the signature through the SDK?

It took ICP a long time to push hard for decentralization, which is why we trust NNS, and for early projects, decentralization is not so great that governance often doesn’t work, and some developers will prefer to keep the ability to update the contract to fix bugs and avoid being attacked. The economy of early dapps is very fragile to operate prematurely giving all container controllers to a black hole address or a dao is not a good thing.

I don’t think we can have it both ways. We either need an upgrade pattern that supports migrations from one canister to another with a general understanding of ‘unupgradeable’ canisters like etherum or we need to have open sourced + governed canisters. Maybe we need a “Audit DAO” that can act as a utility for small projects in exchange for some tokens in the project. Generalizing the governance that way would unify the community on standards, upgrades, and deployment patterns.

3 Likes

Hi! Glad to see that SNS Team are taking this seriously, your work will give developers a lot of confidence.

If publishing all the blocks and state for the SNS subnetwork, will the performance of SNS be lower compared to other subnets? At the same time, will the calculation method of computing resources in SNS change to use cycles bidding?

I would like to have at least one place to store the full history of transactions, a storage subnet or some infura (boundary nodes) might do the trick.

We can store only the hashhead of the token transaction instead of the full record, I think the most important thing is to give the cryptographic proof of the token balance credible.

I’m curious why you want to see the full history of transactions. What would you use that information for? In the physical world, we don’t have a full history of transactions for a dollar bill, for example.

I think the most important thing is to give the cryptographic proof of the token balance credible.

I think the ICP ledger canister already stores a blockchain inside of it (i.e. a blockchain within a blockchain). Is that not sufficient?

2 Likes

Boy do I have the book for you. :joy: Having the financial history on a ledger can/could be very very exciting and change future financial models. I’ll DM you a link.

Interested in this book as well! (Awaits DM :hugs:)

Hi @blockpunk . Thank you for your thoughtful post. We will provide a detailed response to all the relevant points you raise, here are a few things we’d like to make clear right away:

  • The SNS code is open source as is all other code including the NNS and the rest of the IC. All SNS code lives here: ic/rs/sns at master · dfinity/ic · GitHub. We encourage the community to look at it, review it and suggest changes.

  • We’re looking for and into collaborations within the IC community to make SNS tokens available in decentralized exchanges on the IC. The Dfinity foundation is not actively looking into making SNS tokens available in centralized exchanges, any SNS project can do it namely with using/adapting Rosetta (docs here: Integrate with the Internet Computer ledger | Internet Computer Developer Portal).

  • The full SNS ledger transaction history will be available and cryptographically verifiable as the NNS ledger’s already is: Both the NNS and SNS ledgers provide a virtual blockchain where all the transaction history can be downloaded and verified cryptographically: the ledger archives old transactions into a sequence of archive canisters.

  • We’re exploring the possibility of additionally making subnet block history public so that users could rebuild the state locally, along with the tooling to do so: Noteworthy though that these are additional assurances: the transaction history is already downloadable and cryptographically verifiable via the ledger and ledger archive and the SNS ledger code history will be verifiable by looking at the proposal history.

Thank you

8 Likes

How does subnet block history work with upgradable canisters? Is the wasm in the chain for reloading/simulation/verification?