Domains: Independence, bridging, and decentralization

I have some questions around independence, bridging, and decentralization in Domains. First, let me quickly summarize what I understand about the design of domains. Please correct me if I have gotten something wrong.

There can be several domains associated with the consensus chain. Every domain can have several operators. At every slot, for every domain, 0 or more operators are elected as leaders and generate bundles. The consensus chain blocks are formed ‘‘around’’ these bundles. A single block can have multiple bundles that come from different domains.

Seems like the bulk of transaction processing happens off the consensus chain, i.e. in the domains. The consensus chain is responsible for ordering the bundles and the blocks containing those bundles. The domains, on the other hand, are responsible for putting transactions together into bundles, executing them, and maintaining the state of all the accounts. So, basically, the consensus chain is used for data availability (which is what it’s good at) while time-consuming and expensive computation moves off-chain.

Now, some basic questions:

  • Are domains completely ‘‘independent’’ of each other? In particular, do accounts on one domain have anything to do with accounts on other domains (similar to L2s on Ethereum)? So I guess I can have the same wallet address on different domains with different balances.
  • Would it be possible to ‘‘bridge’’ assets / state between domains? Does the consensus chain maintain any state separate from the domains to make this happen? I can see that there is some facility to transfer SSC in the spec, but not much about other things.

Staking and decentralization: Seems like anyone can start a new domain. To become an operator, a minimum deposit, MinOperatorStake, is required.

  • How can we make sure that domains will be decentralized? Is the idea that as a domain becomes popular, e.g. begins generating a substantial amount in transaction fee, more and more operators would like to join? On the flip side, if a domain doesn’t handle much transaction volume, then centralized operation can’t hurt very much anyway (when the sole operator turns malicious).
  • A domain can give the ‘‘perception’’ of decentralization even when there isn’t any. For e.g., after registering a new domain, a malicious entity can stake as ‘‘different’’ operators multiple times, giving the impression that there are multiple operators on the domain when there is effectively only one. Is this problem also mitigated by the idea above, or are there additional protections too?
3 Likes

Thank you for your questions @shashank .

Yes they are completely independent and you can hold different balances on different domains for the same account.

We have cross domain transfers that enable transferring assets between domain and to and forth consensus chain as well. This is not limited to just assets but right now we support moving balances out of the box.
Here is the pallet that move assets between domains - https://github.com/subspace/subspace/tree/main/domains/pallets/transporter

We are currently using optimistic verification of domain execution on Consensus chain using Fraud proof. A domain would need atleast one honest node to detect any malicious behavior and challenge that domain’s block/activity on the Consensus chain.

An operator with enough free balance can create multiple operators each with minimum operator stake. This would be very similar to running multiple validator nodes with different stash accounts. Can you elaborate more on why you might think this is a problem ?

3 Likes

@ved Thank you for responding to the questions.

For the decentralization question, here is another way to present my concern. A lot of storage power would go behind the consensus chain, so we can reasonably expect that it would be decentralized. In particular, we can say that most of the storage power would not be under the control of one entity. However, the situation seems to be a bit different for domains. If it doesn’t require much stake to operate a domain, it could be possible that one entity controls the entirety of stake (or almost all of it), making the domain effectively centralized.

I know that this is not a new or unique concern (one can find it in some other stake-based settings too), but I am curious what measures do we take to mitigate it?

Apologies for delayed response, I was hoping I would get a notification when something changes here.

However, the situation seems to be a bit different for domains. If it doesn’t require much stake to operate a domain, it could be possible that one entity controls the entirety of stake (or almost all of it), making the domain effectively centralized.
I know that this is not a new or unique concern (one can find it in some other stake-based settings too), but I am curious what measures do we take to mitigate it?

Yes, that is expected since creating a new domain is a permissionless operation and a single operator can run entire domain. And that single operator may even produce invalid transactions if there is no other node watching and submitting any fraud proofs. If someone is interested in participating in that domain and are concenred about the security of the domain, then they should run a domain node that can watch the domain txns and submit fraud proof if required. Note: they do not have to be an operator to submit fraud proofs