Skip to main content

User-Defined Partitions

Alphabill is designed such that partitions can be added by users in a permissionless way. These partitions can be anything from the Bitcoin and Ethereum blockchains to a Web2 database.

User-defined partitions

External Smart Contract Platforms​

To make chains interoperable a subset of validators on different chains may join the Alphabill framework as a partition, that is, they will request a partition ID. connect to the Root Chain and use a unicity certificate, generated by the Root Chain to certify its internal state. That state can then be transported across partition boundaries, verified, and acted upon in other partitions.

For example, to transfer a user token in Alphabill into an Ethereum smart contract, a user will first transfer the Alphabill token into a state which gives specific control to an Ethereum smart contract. The proof that control has been given will be generated by the user and sent to the Ethereum smart contract address. As the Ethereum validators are connected to the Root Chain, they share a common root of trust, and the smart contract can verify the proof. The smart contract will then credit its internal account structure, execute, and redistribute value amongst its internal accounts. If a user wishes to withdraw tokens from the smart contract they can request a withdrawal, the smart contract will debit the user's account and then generate a proof that can be used by the user to reclaim ownership of the token on the Alphabill User Token Partition.

Alphabill as a Cross-Chain Interoperability Layer​

It is often claimed within the crypto community1 that cross-chain communication is impossible without trusted third parties. However, they assume that an atomic swap requires solving the following problem:

There are two chains X and Y. One wants to add a (swap) transaction t to both chains such that t is either added as a valid transaction to both chains, or none of the chains.

This task is indeed known to be impossible without a third referencing party as proved in 1980 by Even and Yacobi2. However, the atomic swap solution in Alphabill does not require a transaction t be simultaneously and atomically added to both chains. Instead, all four possibilities are considered:

  • t is included in both X and Y
  • t is included only in X
  • t is included only in Y
  • t is included in neither of the chains

The predicate of the transaction t guarantees that only in the first case, t changes the ownership of a unit. This is achieved by using a special predicate in t that guarantees the next properties:

  • The (claimed) new owner can make the next transaction only by presenting evidence that t was accepted in the other chain.
  • The previous owner can make the next transaction only by presenting evidence that t was not (and will not be) accepted in the other chain.

The Alphabill Atomicity Partition, together with user-defined partitions in which a subset of other chain validators are connected to the Root Chain, makes it possible to implement decentralized cross-chain swaps and other inter-blockchain operations in an atomic trustless manner.

Centralized Web2 Applications​

The user-defined partitions do not need to be decentralized. For example, it could be an existing enterprise application. The application can request a partition ID, receive, and verify tokens and then generate proofs to reallocate those tokens based on the application logic. This is similar to Ethereum layer 2 logic, but enables any type of application, including existing enterprise and web services to participate in the framework.

Oracles​

A similar approach allows for external data sources to provide certified data to be used within the Alphabill platform. This can be consensus Oracles such as Chainlink or Gnosis, centralized external market data providers such as exchanges or hardware Oracles such as IOT devices. In the case of exchanges, there is a single source of truth for market data—the exchange publishes the data. To make this data available in Alphabill, an exchange will request a partition ID and use the Unicity Certificate service from the Root Chain to certify their data and allow users to transfer that data to be used in a relevant smart contract where it can be verified as authentic.

1 For example, SoK: Communication Across Distributed Ledgers
2 S. Even and Y. Yacobi. Relations among public key signature systems. Technical Report 175, Computer Science Dept., Technion, Haifa, Israel, March. 1980