Last week . The article triggered a lot of interesting debates between thought leaders in the security token community, so I’ve decided to dig a bit deeper into some of the ideas. Before I go any further, I should say that I don’t see a clear path to implement any of these ideas in proof-of-work networks like Ethereum. As you might know, . Also, the ideas presented this are just the result of some high level analysis on this problem and are likely to have a few flaws. However, hopefully they can serve as a starting point for what I consider is an important aspect in the future of crypto-securities. I wrote about the need for a different consensus model for security token protocols I don’t believe the current version Ethereum is the greatest fit to model sophisticated security token transactions To deep dive into the thesis of a new consensus protocol for security token, I propose three simple steps: Understand the process of validating security token transactions. Discuss the centralized validation model in security token platforms Propose a consensus protocol for security token transactions (at a high level) The thesis of a new consensus protocol for security tokens seems more sophisticated than it really is. The idea becomes incredibly obvious once we analyze the nature of a security token transaction. Understanding Transaction Validation in Security Tokens A security token transaction is just a tokenized transaction that needs to be compliant with a series of securities law. From that perspective, you can think about the process of validating a security token transaction in two main steps: Validating the compliance requirements of the transaction. Validating the financial legitimacy of a transaction before its committed to the blockchain. We can visualize that process using a very simple flowchart. In the current blockchain ecosystem, we have plenty of mechanisms for step 2. Practical byzantine fault tolerance algorithm (PBFT), the proof-of-work algorithm(PoW) ,the proof-of-stake algorithm (PoS), and the delegated proof-of-stake algorithm (DPoS) are some of the consensus models that have found their way into mainstream blockchain implementations. The key to validating security token transactions is to combine those consensus models with existing compliance checkpoints. The first wave of tokenization platforms have adopted a simple, centralized model for ensuring those compliance checkpoints which, in my opinion, comes with its own set of problems. The White-List Fallacy: Problems with Centralized Transaction Validation I am not a decentralization purist. Maybe because I have too many scars from trying to implement decentralized architectures at scale. Furthermore, I’ve expressed the idea that security tokens are a much-needed recentralization vector in the crypto space. However, I think the current 100% centralized compliance model in security token architectures is not a viable option in the long term. In the current generation of security token architectures, compliance validations are enforced by centralized services that perform know-your-customer(KYC) or anti-money-laundering(AML) validations against a predefined white-list. While that approach represents a simple compliance mechanism for the first wave of security tokens is hardly a viable option in the long term. Without reading the decentralization gospel, I think the centralized compliance model have some very tangible limitations: Imagine spamming a blockchain with a bunch of invalid transactions to saturate the compliance validators. Subject to Classic Security Attacks: Overtime, centralized compliance validators can gain too much influence over the lifecycle of transactions. Influence and Dependencies: The centralized compliance validation models doesn’t include any incentives to prevent bad behaviors from validators. Lack of Incentives: I can go on for an entire post but hopefully you get the idea. As security tokens evolve, we need to transition towards a decentralized, consensus-based transaction validation process. A Two-Phase Consensus Model for Security Tokens Remember the main two steps in a security token transaction? Validate the compliance and the financial viability of the transaction? How about if we accomplish that validation in a two-phase consensus process. Imagine a security token network with two main types of nodes: · These are nodes that can validate a specific type of compliance such as KYC. AML, capital requirements or jurisdictional validations in a security token transaction. The network will have different types of compliance validators depending on the type of compliance they enforce. Compliance Validators: · These are nodes that perform traditional checkpoints (double spend, etc.) on a security token transaction before is committed to a blockchain. Validators: Compliance validators need to well-known identities in a blockchain networks while validators can enjoy certain level of anonymity. This is completely optional of course. Based on the requirements of a transaction, a security token consensus protocol can validate the transaction in two main phases: Achieve consensus about the compliance of the transaction Phase I: Achieve consensus about the financial legitimacy of the transaction Phase II: Phase I Imagine a financial security token transaction that specifies a series of basic requirements: a) Only citizens of specific countries can own the underlying security product. b) Token holders need to have $1M liquidity at their disposal. c) Investors need to have access to financial disclosures of the underlying security no older than three months. Based on those requirements, a security token network can select a random group of Compliance Validators that arrive to consensus about the viability of the transaction. The network will broadcast a series of assertions about the transaction( privacy is an interesting point here) , Compliance Validators will inspect those assertions and issue a vote about the validity of the transaction. Compliance Validators need to be reputable, well-known identities such as banks or government agencies. Considering that factor, Proof of Authority(PoA) is an interesting option to implement a consensus model between compliance validators as identities and reputation become the main staking mechanism. However, while pure PoA will work beautifully in permissioned blockchains, it lacks the right incentives to work efficiently in public networks. From that perspective, combining PoA with a tokenized incentive model in which Compliance Validators are compensated based on their work, its an interesting idea. More about this in part II. Phase II After the security token transaction has been verified by the Compliance Validator network, it can be processed by second group of nodes that will try to achieve consensus about the financial viability of the trade. There is no need to reinvent much here as we have consensus protocols that work well in this area. To maintain certain level of symmetry to the PoA model, I believe some of the ideas behind delegated proof of stake(DPoS) are very relevant in this area. At this level, Validators might operate under semi-anonymous conditions just as they do in mainstream blockchains. I will explore this concept further in part II. It’s Not That Simple The two-phase consensus model is certainly a viable option for security tokens but one that is not very trivial to implement. As I mentioned in the introduction, at the moment, I don’t see a clear path to implement this type of consensus protocol using Ethereum. Furthermore, a two-phase consensus protocol opens the door to all sorts of game theoretic attacks that need to be addressed. That will be the focus on the second part of this essay.

BUNCH

Read My Stories

Too Long; Didn't Read

Discover Saakuru: Web3 Mass-Adoption with 0-FEES

Some Ideas About a Consensus Protocol for Security Tokens: Part I

Too Long; Didn't Read

Company Mentioned

Jesus Rodriguez

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Some Ideas About a Consensus Protocol for Security Tokens: Part I

Too Long; Didn't Read

Company Mentioned

Jesus Rodriguez

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES