SIP: 2 Title: Network-enforced Business Rulesets Author: Sidhujag <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/syscoin/sips/wiki/Comments:SIP-0002 Status: Draft Type: Standards Track Created: 2020-07-19
Many projects today aim to interface stablecoins and crypto assets with existing financial frameworks. These frameworks have evolved to curtail or otherwise deal with tax evasion, fraud, terrorist activity and money laundering through know your client (KYC) and Anti-money laundering (AML) standards. Integrations need to follow these and future standards in order to comply. We are at a crossroads where many technology pioneers expect financial systems to adapt, while financial systems themselves require integrated technologies to meet requirements which have been well thought out and market tested over generations. This proposal presents a dialectic solution based approach which makes it possible to realize the benefits of decentralized ledger technology without sacrificing compliance requirements. This paper presents an opt-in approach that grants businesses the ability to run next-generation asset systems which comply and in addition, realize or create benefits and efficiencies that did not exist prior to the crypto-economic expansion. While previous efforts have relied on consortium-based/permissioned ledgers, the settlement of value on those systems presented risks that are outweighed by the benefits of censorship-resistant and legally neutral permissionless crypto-economic blockchain systems which make no distinctions between market participants. The ability to leverage the tremendous security of the Bitcoin network through settlement of value would be ideal in combination with legally compliant transferability of assets. This methodology reduces insurance and custodial service costs, provides settlement finality that cannot be manipulated, and increases the overall efficiency concerning the notion of sovereign ownership of value.
The Syscoin network presents this option. It is based on the Bitcoin network protocol and is merge-mined with Bitcoin. As a result, Syscoin promotes sharing the network security of Bitcoin while also presenting unique features for businesses that cannot be achieved using Bitcoin itself, such as the ability to tokenize assets and scale asset microtransactions in a manner that presents near real-time fulfillment through the use of a DAG (Directed Acyclic Graph) payment mechanism called Z-DAG.
Compliance at scale must be provided without affecting the underlying premise of global settlement opportunities, and without hindering other non-compliant market participants for blockchain technology to be of value to both finance and individuals seeking sovereign value ownership; scalable financial inclusivity without sacrificing compliance.
The system must also provide compliance without requiring it in cases where it is not required. For assets that do require it, consensus of mandatory compliance is enforced among all participants. This provides ease-of-integration into existing financial markets.
This document proposes a standard consensus rule which applies witness signature enforcement for Syscoin Platform token transactions that 'opt-in'. The underlying premise is that compliance is necessary and provided, however scalability is also required when dealing with P2P based BFT (Byzantine Fault Tolerant) crypto-economic consensus systems that inherently lack the scalability required for global adoption. With the requirement of scalability in mind, we believe we have found a way to accommodate all requirements and provide the functionality needed for full compliance regardless of jurisdiction.
Pre-compliance is the "holy grail" use case for crypto assets that adhere to global regulations and monetary transmission policies. These policies can vary dramatically between jurisdictions and are subject to change. This makes complying to the logic of such policies within the consensus layer very difficult, especially since code is generally considered immutable once deployed.
Since checks are made prior to validation, pre-compliance leads to post-compliance in effect. Compliance is simply proving that no transaction may take place in a network until the necessary preliminary policy checks - auditable by policy makers at any time - have been met. The primary concern among policy makers concerning the compliance of crypto assets is that typically any pre-compliance strategy involves changes that are superfluous. As a result, they may be adapted by wallets and services, but are not enforced within the consensus layer. Therefore, they lack an objectively enforceable mechanism that prevents bad actors from executing transactions that skip these checks. Doing so on the network validation layer will provide assurance to policy makers by addressing these concerns. Furthermore, the logic of the system is designed with business needs in mind and can adapt to legal clarifications or frameworks adapting to the industry. This compliance framework consists in part of on-chain analysis tools such as QLUE or BitRank which will further promote transaction compliance with address monitoring. Such monitoring is necessary in enabling crypto assets to surpass what is requested by today's KYC/AML regulations, and allows asset settlement within a permissionless system while conforming to specific regulations and compliance checks of various jurisdictions. With such monitoring, post-validation such as freezing and black-listing can be enabled without requiring consensus changes, as transfers may be blocked by pre-compliance verifications by the end-points on future transactions.
Compliance is not the only use case. Business rules like Auxiliary Fees (fees a business extracts per transaction as part of Cost of Doing Business) can be applied as a revenue model to offset running costs or part of a business token economic model. These fees typically were driven by either wallet applications or central APIs. Now they can be enforced by consensus and may be adaptable at any time based on evolving business requirements. Other use-cases pertaining to crypto-asset verification in enterprise are also possible as traditional business flows can be integrated whilst still enjoying the censorship resistant settlement and tamper resistant auditability of decentralized ledgers. End-point verification ensures these business rules are applied to a transaction and approve/reject the execution of these transactions based on criteria defined by the business itself. API-driven connectivity ensures that wallets, services and exchanges can adapt to requirements by consuming APIs that provide conformity to the process of performing checks and obtaining witness signatures required for the transaction to be validated successfully.
Syscoin enhances a witness field and requires signature sign-off by this witness for all transfers of the token, rather than management transactions that change the asset specification itself. On the API side it is open; left to the discretion of implementation designers. The following presents a potential reference design: an API, such as the SyscoinJS API, knows which Program Manager end-point to call based on a registry, or perhaps the URL of the end-point is encoded in the public data field of the asset definition. The end-point is then requested to share its business requirements. For example, if extra fees (Auxiliary fees) are to be enforced, they can be described in the response so the SyscoinJS API can generate the proper inputs/outputs for the transaction prior to obtaining a Witness signature. Upon crafting the final transaction, the end-point is queried for a Witness signature allowing validation on the network. In this example, the end-point may either implement a naive mechanism of storing a private key for signing after conducting basic checks (KYC/AML, on-chain analysis, black/white list approvals). Upon approval sign with the private key of the witness address defined in the Asset Witness field. To reduce central points of attack on the server holding the private key, threshold signatures, or Shamir's Secret Sharing strategies, can be used to offload the storage of the private key across multiple end-points. These end-points should only be known by the Program Manager end-point or connected amongst themselves to avoid DOS vulnerabilities. Either of the end-points can assume the role of coordinator if the Program Manager end-point becomes unresponsive.
The Program Manager end-point will require effective infrastructure management, colocation per query, presence within a CDN, as well as automated backups to ensure resilience and fault tolerance. A DRP (disaster recovery plan) should also be established to ensure continued business operations under duress. The private key itself can be further protected by key sharding or threshold signatures so that even if some end-points do not respond in a timely manner, not all need to respond in order to successfully sign a transaction.
This does not apply to all transactions globally. It will only apply to assets that define an address as the witness field of the asset. The specification presents as follows:
ASSET_UPDATE_ADMIN=1, // "god mode" flag, governs flags field below
ASSET_UPDATE_DATA=2, // can you update public data field?
ASSET_UPDATE_CONTRACT=4, // can you update smart contract?
ASSET_UPDATE_SUPPLY=8, // can you update supply?
ASSET_UPDATE_FLAGS=16, // can you update flags? To lock-down the asset spec permanently, disable this one and admin flag as well
ASSET_UPDATE_ALL=31
// ERC20 smart contract to connect to the Sysethereum bridge
std::vector<unsigned char> vchContract;
// if changing the ERC20 smart contract must specify the previous one for disconnect/re-org purposes
std::vector<unsigned char> vchPrevContract;
// asset symbol 1-8 characters
std::string strSymbol;
// public data field, JSON input for fields that are relevant like description and end-point definitions
std::vector<unsigned char> vchPubData;
// previous public data in case public data is changing for disconnect/re-org purposes
std::vector<unsigned char> vchPrevPubData;
// balance being updated or defined upon creation of asset
uint64_t nBalance;
// total supply only set when creating an asset
uint64_t nTotalSupply;
// maximum supply set when creating an asset
uint64_t nMaxSupply;
// precision for this asset defined for user display purposes
unsigned char nPrecision;
// update flags mask of values from the enum above
unsigned char nUpdateFlags;
// previous flags if flags are changing for disconnect/re-org purposes
unsigned char nPrevUpdateFlags;
// NEW: witness required to sign on all transactions for this asset
std::string strWitnessAddress;
// NEW: previous witness required to sign on all transactions for this asset if witness address is changed for disconnect/re-org purposes
std::string strPrevWitnessAddress;
The above presents the new strWitnessAddress field. If set, it will require consensus to validate that there exists an input from this address which will implicitly verify the signature of that input through the OP_CHECKSIG script logic.
The overall design presents as follows:
For integrations from services such as exchanges, wallets and providers, those that integrate the Syscoin API will not be required to perform any further actions than they would normally require. The Syscoin API will do all complete all necessary work to call end-points and ensure transactions are created and submitted as valid. Nothing changes compared to existing crypto wallet implementations if using the existing Syscoin API. The diagram is provided for illustrative purposes to demonstrate what the Syscoin API would do to ensure pre-compliance in accordance with this proposal.
On the consensus layer, the SPT asset definition will include one more field for a witness address. If this field is defined, any transactions involving asset allocations (not asset update/transfer) will require the witness signature from that address based on the transaction signature hash. Moreover, doing so will mean one more input will be used in creating a simple transfer for an asset allocation, but the cost of a simple input is fairly minimal. Just one signature verification must occur, regardless of how many parties signed off on it through the end-points (either via threshold signature or secret key sharing).
On-chain there will only be a single signature required by a witness as defined in the SPT. However, offchain; one may wish to use multiple end-points to recreate the necessary signature for the witness validation. To reduce central bottlenecks in the system while ensuring performance, one may choose to use secret sharing or threshold signatures (former if performance is of more concern, latter if privacy). Depending on market conditions, one may choose to deploy different strategies at any time without requiring any changes to the underlying consensus validation.
Shamir's Secret Sharing allows one to recreate a key yet retain compatibility with the underlying signature verification and validation process. The shards are distributed among peers and a central coordinator extracts and joins them together up to a threshold level that re-creates the private key necessary for signing. This potentially leads to private key leakage but also promotes performance benefits aswell. This method solves issues of availability should that be a primary concern. Private key leaking may not a primary concern, however, so long as the coordinator service is not confiscated, and if it is, the managers of the SPT would be able to replace the key with a new one and re-deploy on new secured services without succumbing to the further ramifications of any such attacks. If the concern around privacy is higher than performance, then a threshold signature scheme can be employed at some cost of performance (requires roundtrip interactivity amongst end-point peers and cryptographic primitives that take a non-trivial amount of CPU cycles and memory). Secure communication and encrypted channels can be created to avoid man-in-the-middle attacks or eavesdropping. However, the central coordinator presents the primary bottleneck in the system. This can be easily mitigated as redeployment is simple if a breach occurs and no funds are at risk, rest or live. The attacker can merely prevent or not-prevent certain transactions from validating on the network, and the non-preventative case can be mitigated by further post-compliance measures to block addresses.
To address single points of failure, managers of SPTs may choose to distribute signature creation to offload risk and ensure a higher degree of control over situations where certain API service end-points are inaccessible. One may wish to implement a threshold that is high enough to justify validation securely, while also retaining tolerance against Byzantine Faults. There are different strategies to employees signing the witness signature required for transaction validation.
As per BIP-0340, with Schnorr signatures, participants can aggregate their public keys into a single public key for which they can jointly sign. This allows k-of-n multi-signatures that, from a verifier's perspective, are no different from ordinary signatures, providing improved privacy and efficiency versus CHECKMULTISIG or other means.
Moreover, Schnorr signatures are compatible with distributed key generation, which enables interactive threshold signatures schemes, e.g., the schemes described by Stinson and Strobl (2001) or Genaro, Jarecki and Krawczyk (2003). These protocols make it possible to realize k-of-n threshold signatures, which ensure that any subset of size k of the set of n signers can sign, but no subset of size less than k can produce a valid Schnorr signature. However, the practicality of the existing schemes is limited. Most schemes in the literature have been proven secure only for the case k-1 < n/2, are not secure when used concurrently in multiple sessions, or they require a reliable broadcast mechanism to be secure. Further research is necessary to improve this situation.
Typically a multi-signature scheme on-chain will lead to n-1 signatures required and verified on-chain. This is evidently the most secure from a single-point-of-attack scenario but it is not practical for larger k-of-n values.
Other works include using BLS signatures as described by Fast and Scalable BLS Threshold Signatures, which are user friendly and allow end-points to distribute keys while at rest without necessitating the re-creation of the private key required for signatures because of public key/signature aggregation. An example op-code construction is described here BLS signature introduction.
ECDSA threshold signatures are also possible as described by Adam Gągol, Jędrzej Kula, Damian Straszak and Michał Świętek (2020). This will retain compatibility with the current ECDSA infrastructure in Syscoin. However, if we move to Schnorr we can apply Schnorr threshold signatures instead in similar constructs.
ECDSA threshold signatures rely on random numbers as part of their constructions which BLS signatures do not. BLS signatures are explicitly isomorphic, making them easy to work in aggregate form. Unfortunately, verification costs suffer compared to ECDSA. Some benchmark figures are shown in the links above. BLS signatures do not use random number generation as part of their construction nor aggregation.
Because of this random number dependency along with other factors outside of the scope of this SIP, ECDSA uses zero-knowledge proofs as part of their efficient construction for threshold signatures among end-points. Multiple rounds of interactivity between end-points are needed to ensure they are acting as honest, valid signees. The paper by Gągol et al (2020) attempts to address this by using BLS signature construction as a standard for performance but applied to ECDSA.
With Syscoin's UTXO based Syscoin Platform Tokens, it is possible to establish payment channels such as those in the BOLT spec using HTLC on-chain contracts to enforce off-chain payments amongst peers.
The BOLT specification for Lightning Network payments is compatible with this approach as the additional input would be signed upon open or closing a channel. The compliance verification would require proof of provenance of honest funds by disclosing the offchain trades which can be independently verified via cryptographic analysis and tooling with provided information.
Allowing offchain payments and specifically the BOLT specification, are critical in the acceptance of this proposal as although Syscoin offers on-chain scalability through the use of Z-DAG, the bandwidth requirements of global scale would not permit every user to operate on-chain without competing for block space. The fee market mechanism for Z-DAG is more efficient than that of Bitcoin's. The focus is to settle within some extended time period and not in the next block with some assurance of double-spend protection, it is nevertheless non-conducive on its own in regard to global adoption for efficient, fast, and convenient payments to place all transactions on-chain and require bandwidth across the network for every user.
A hybrid off-chain/on-chain solution is presented by Syscoin where on-chain is used for slightly higher fees to incentivize participants to use off-chain without sacrificing trustlessness or decentralization, yet in this case remain compliant where applicable. Z-DAG ideally is utilized when there are occasional resilience issues with off-chain payments which are inevitable since there is no fault tolerance in the use of off-chain globally non-consensus based payments.
Thanks goes to many industry veterans that made this document possible. Individuals and companies including but not limited to Marc Nicholson of Blockchain Foundry (Discovery sessions, market analysis and validation), Lance Morginn of Blockchain Intelligence Group (specification validation), Zak Cole of Whiteblock.io (proofing), Bradley Stephenson of Syscoin Foundation (proofing), and Amardeep Badyal (proofing).