Extensible Multiple signatures (“XSIG”) with the Extensible Blockchain Object Model (“SagaOS”)
Continuing the series on Accounts and Smart Objects, from David Beberman, CTO
The usual way to key an account is to have the account owner hold a private key and the public key or a deterministic derivation of it used as the account address. This works great for a single user provided the user does not lose the key, or have it stolen. An analogy is a house with only one key to the front door. You don’t want to put that key under the mat. Is a user wishes to share an account, they could create a second account from the first account, put whatever they want to share in that account and give the key to that account whomever they want to share it with. Of course, the user can’t control if the person they give that key to, decides to say post it on a social media site.
What a user would want is the ability to control the access of keys to the user’s account. For example, they might want to give a key out to a user and be able to revoke it later. Or, they might want to hand out pieces of a key to multiple people to hold, such that, if the user loses their key, they can regain access by collecting the pieces of the key from such people, and recreate the key, or alternatively rekey the account with the recovered key. There are multiple variations on this. Schnorr Multi-Signatures[1] are an example of multisignatures.
The concept of multiple signatures for controlling keys has many applications, but implementing a signature scheme often requires “hard forking” a blockchain with new code. In the case of a token smart contract, a signature scheme can be implemented without the hard fork, but changing it would likely require a hard fork. Although creating a smart contract for each user account could be used to implement a multi-signature scheme on a per account basis, changing the signature scheme used in the smart contract would likely require the user to create a new account. This is a far better situation than a hard fork, but wouldn’t it be even better if there was a way to support all signature models, even new ones that haven’t been discovered yet, in a natural way?
Hard forks, replacing smart contract accounts, and similar all are technical solutions to changes, updates, or replacements of a signature scheme. Some are more, some are less acceptable to users of blockchain accounts. SagaChain introduces a new concept for changes, updates and replacements of signature schemes using the Extensible Multiple Signatures (“XSIG”)[2] object built on the Extensible Blockchain Object Model (“XBOM”) platform.
A user off SagaChain may instantiate an XSIG object and add it to the user’s account. The XSIG object is then used for signature verification. The specifics of the signature scheme including the number of signatures needed, subset of signatures, etc. are part of the XSIG data. Further, the signature algorithm used is defined by the XSIG class or subclass. This enables not only adding new signature algorithms to SagaChain as they are discovered, but updating an existing user account by replacing the signature object in the account.
As shown below in an abstract diagram, an account might contain a list of signature objects enabling multiple ways to unlock the account. Think of an analogy of a house having more than one door with more than one type of key.
The following steps give an idea of how to create and install a signature object in a SagaChain account:
1. Transaction -> XBOM user account object instantiation — creates an account as a single keyed account
2. Transaction -> New account -> XSIG object instantiation — creates a new signature object with any needed initialization parameters
3. Transaction -> New account -> Install New Signature Object — adds the XSIG to the list of signature objects.
All future transactions now will use the new signature object as one of the signature objects to verify signatures in the transactions. If verification fails, across all signature objects in the signature object list, the transaction fails with a signature verification error. Multiple variations of this are possible including specifying permissions for transactions allowed on an account with a specific signature object, replacing signature objects, allowing for multiple transactions with separate signatures to be sent over a period of time to pass verification of a signature object, etc.
The flexibility of the XBOM enables many variations of account structure and use-cases, leveraging a more natural way to reuse code, and work in an object-oriented manner. The XSIG is only one such solution.
To learn more about Prasaga’s patent pending blockchain technology including the Extensible Blockchain Object Model, the Extensible Multiple Signature Object, the Extensible Smart Object Asset and scalable sharding consensus algorithms, contact us through our website at prasaga.com or email us at info@prasaga.com.
[1] For an introduction see: https://hackernoon.com/a-brief-intro-to-bitcoin-schnorr-multi-signatures-b9ef052374c5
[2] The Patent — US-20220326981-A1- Extensible Blockchain Object Model (XBOM) Foundation Classes and Objects and Supporting Data Structures is an exciting new technology from Prasaga that defines and implements the smart class and smart object model in place of the smart contract model.
