Dapp deployment on quai

General
1

As we all know Quai has 13 chains that are all independent, but have coincident blocks with eachother to allow the passthrough of data between them. How would this influence dapps that would like to deploy on Quai? Would they have to deploy on all 13 chains or there will be a mechanism for an account on Cyprus-1 to interact with a dapp deployed on Paxos-3 similarly to external transactions?

20 Likes
2

I suspect this depends on the type of dApp. A token contract, similar to an ERC20, might require a contract to be deployed on multiple chains, and a signalling mechanism between the “sister contracts” on each chain.

Suppose I want to deploy a token on Quai. I would likely deploy the token contract on all 13 chains. Each contract would need to know two things:

  1. who are my sister contracts?
  2. did a message come from my sister contract or an imposter?

If you can answer these two questions (this is trivial, but I’ll save the details for another post), then you can coordinate mints/burns between sister contracts, to effectively move tokens between chains.

Consider the the following scenario: Alice wants to send tokens from her account in Cypress-1 to Bob’s account in Paxos-2. The workflow could look as follows:

  1. Alice signs transaction to transfer 100 tokens to Bob, and sends her transaction to the token contract in Cypress-1
  2. The contract burns 100 tokens and emits an ETX to Paxos-2, instructing the Paxos-2 sister contract to mint 100 tokens to Bob’s address
  3. The ETX will eventually propagate across the network (trustlessly via merged mining), until it becomes “playable” in Paxos-2
  4. A miner in Paxos-2 will mine the ETX into a block, where it can be processed like a normal transaction
  5. The token contract in Paxos-2 must confirm that the ETX came from her sister contract in Cypress-1, by simply checking the ETX ‘from’ field
    • this is trustless, because no actor can forge this message from the Cypress-1 contract without 51% of network hashrate (likely much more to pull off such an attack with any speed or finality)
  6. The token contract then mints 100 tokens to Bob’s account

The mechanism to perform this cross-chain token transfer actually is not very complicated, but it will take some time for the ETX to propagate across the network.

This, obviously, only discusses token contracts. Other contracts might require different cross-chain communication mechanisms, but in my experience so far, every dApp scenario I’ve thought of has been easy enough to work out, and actually kind of fun :sweat_smile:

12 Likes
3

I’m very interested to see the first implementation of cross-chain referencing contracts as it allows solidity developers to do something that has never been done before. Move value between chains without relying on centralized bridging services/other insecure options. Lots of cool things to be built!

Quick question on the actual implementation of referencing contracts: when deploying the sister contracts to all 13 chains, how would a developer make the first deployed contract aware of the others? Obviously not sure exactly sure what the referencing language inside of the contract would look like, but I would assume that each of the contract addresses on other chains would have to be hard coded in order to be aware of them. Which would lead to a bit of a chicken and the egg dilemma…

Curious to hear everyone’s ideas on other ways “contract awareness” could be established without hard-coding or other ways developers could work around this.

9 Likes
4

Since the network scales horizontally with addition of more chains, I was wondering whether you can scale a dApp within Quai in a similar way. Say, you start out with a smart contract deployed on 6 chains. Then, as you go on with deployment, you realise that you may benefit from adding another zone chain because of the user demand of your dApp. Or, another scenario, you deploy on all 13 chains, and then Quai adds the 14th one that you would like to include into your smart contract to maximise throughput. So, there are two questions that I have about this:

  1. Would that be possible to make an impostor chain a sister chain (ie deploy on more chains than your originally started with) in-flight?
  2. Is there any benefit to starting off with <13 chains under the assumption that the throughput is ‘high enough’?
9 Likes
5

I am very interested in this question as well and am excited to see how people choose to use Quai’s unique architecture when building. I think early on there will be a smart contract standard for the equivalent of an ERC20/ERC721 (are we calling it QRC on Quai? I’ll assume so for now) to allow them to seamlessly exist and be transferred across all of Quai’s chains. I am interested to see how the modularity of Quai’s architecture will influence these standards though. For example, if another chain is added to Quai (e.g. a fourth Region with three additional Zone chains) will there be a way to auto-integrate these new chains into the pre-existing multi-chain QRC20/721s to allow them to be transferred to the added region and zone chains?

In regards to DApps, I would imagine they’ll start off utilizing a single chain and then expand into other regions and zones. For example, I could see a DEX launching in Region 1, Zone 1 to begin with, but quickly expanding to have support and liquidity in other Region and Zone chains. How does everyone else think a DEX should be architected to take full advantage of Quai’s multi-chain architecture?

6 Likes
6

I have different curiosity and it’s about complexity of the strcuture of how dapps will work on 13 quai chains. If all the 13 chains are independent but communicate through coincident block, the fact a SM contract needed to be deployed on each chain as it deem necessary and then its IBC to communicate to sister dapp, that’s complex. thus this will be more problem to contract/project deployers, if I am one I had think a different approach.

All chains share thesame set of security parameter as well as decentralization, I don’t know how wallet on the entire chain will work, if per each independent chain we need different configuration from users end to intereact then for now I have no idea for further research but may be later, but if a single user address has direct access to all chains without altering network configuration then I don’t know if this can open a new discussion.

Instead of deploying same contract on different chains and its messaging system, may be have a single messaging summary deploy as a contract on others, so when a user trigger the messaging contract on whatever the chains, it then trigger the original contract from it’s first chain. Some sort of L2 and L1, only that in this scenario, the L2 act as L1 and the L1 act as L2.

Example, let’s say a contract is deploy on Hydra, then the messaging summary deployed in paxos, so users trigger the messaging in paxos, then the messaging prompt the original contract in Hydra and user relay his queries for execution.

I am not a dev, just good with business model design and how blockchain architecture can be utilize to solve problems of humanity. After further read I may add and learn from others too.

5 Likes
7

Quai has a total of 13 chains so what does each of these chains do, can you tell me more

2 Likes
8

Great question. There’s several ways to do it, but I imagine a simple TOFU initialization sequence is simplest. Basically, the token contract would need two additional features:

  1. Each contract has 12 “slots” to specify the sister contract address on all 13 chains. These slots are empty when initially deployed.
  2. Each contract has a “owner” which can update those slots only once (see TOFU^). Once the owner has assigned the sister contract addresses, they can never change.

Then, to deploy a cross chain token contract, you would:

  1. on all 13 chains, deploy the contract and collect each contract address
  2. after all contracts have been deployed, go back to all 13 chains and assign the 12 sister contract addresses to each contract.

After this, anyone can independently verify that the correct sister contracts were set, and there is no trust necessary to interact with the token system. This is just my first proposal… someone else may have a better idea :sweat_smile:

9 Likes
9

If the contract is written correctly, this should be trivial to avoid (see the TOFU setup I proposed before). But you are right this should be considered when writing such a cross-chain contract.

This is a very interesting question… I don’t know. Maybe there are some dApps out there that would prefer to constrain their users to only use a subset of chains? If you have an example of this, I would love to hear about it :slight_smile:

5 Likes
10

Interesting thoughts. Using an L2 communication method to coordinate state across chains will likely cause centralization & trust issues (this essentially what trusted bridges are today, and we’ve all seen how badly that can go). The reasons to use coincident blocks for cross chain signalling are thus:

  1. coincident blocks enable trustless bridging– provide a cryptographic link between chains, so there is no need to trust a central coordinator, relayer, etc

  2. transactions passing through coincident blocks will inherently achieve the same finality (at the same speed) as the two chains which are communicating. e.g. if a message is sent from Cypress-1 to Cypress-2, then they only need to wait for the coincident Cypress region blocks to “finalize” that message. This is precisely the same degree of finality which those two chains can share. If a cypress re-org happened, then the message would re-org safely in that process, so there is no security concern with synchronization to an L2.

Essentially, coincident blocks are the only way to trustlessly signal between chains. Coincident blocks are a cryptographic commitment to the state of both states (i.e. merged state), which is as good as you can ask for when you want to communicate a message which relates to the state of both chains. Other solutions would introduce some degree of trust & centralization, which we obviously want to avoid.

The whitepaper explains it best, but in short, the 13 chains form a hierarchy of merge mined shards. The key innovation is that the hierarchy provides scalability without sacrificing security. Lower level chains can confirm transactions at a high rate, and these transactions will eventually achieve the same degree of finality (in terms of byzantine fault tolerance) as the chains are merge mined together.

The goal is to handle the transactional volume necessary for global commerce, without compromising decentralization or byzantine fault tolerance.

5 Likes
11

Really took some thinking, this one :sweat_smile:
I imagined two pathways that you could take depending on the blocktime of the chain you pick.
If you go with Prime only, you could, analogically to bitcoin, create “the digital gold” (lol) That might be redundant though as I don’t know a use case for digital gold apart from trading. Another idea for the slower version of an app could be some
If you build on Zone chain(s), then maybe you could create a private token that has the least communication possible with other ones?

3 Likes
12

after I observed the explanation about TOFU, it was very impressive, but this must really be tested to enter the test as well so that we know how the actual TOFU performance results ,and or this has entered the test with the team ?

1 Like