Crown Blockchain: Platform Overview
This is a summary of the Crown Blockchain Platform. Design of the Crown Platform is based on ideas lined up in the Crown Whitepapers which contain information about our identity and technical vision of how to create a next generation blockchain platform. The full document containing information about the technical details is available here.
What is the Crown Platform?
Crown Platform is a Blockchain-as-a-Service cloud platform for building any new economy businesses or applications to participate in a resilient, efficient ecosystem. Crown Platform is a project to take Crown on to the next level. So, what kind of platform is that?
In the modern world, cloud computing is a very useful paradigm which enables access to shared pools of configurable resources like servers, storage, network etc. Different cloud computing providers offer different models on a “as a service” basis: Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service etc. Below we show how responsibilities are divided between consumers and providers:
The Crown platform is similar to the Platform-as-a-Service approach, where Masternodes and Systemnodes provide infrastructure (virtualization, servers, storage, networking etc.) that enforces integrity and resilience and Crown Platform Core and SDKs provide software tools (middleware, runtime) to enable the creation of new economy applications. Since there is no central unit which manages all the servers, this infrastructure allows businesses to build a distributed cloud platform for development of classic and decentralized application services on top of it, using the Crown Platform.
In the simplest use case, Systemnodes act as Application Service Providers. This business model for providing services is good for a limited number of users. But such model does not scale, is not fault-tolerant and does not have other properties of the “as-a-service” approach. That’s why another, more progressive, use case is to use Systemnodes as clustered hosting providers or gateways to the Crown Platform, where they act as cluster managers or load balancers. Technologies like Docker Swarm can be used in order to create clusters behind the gateway and dynamically manage the load. Multiple Systemnodes can be connected to the same application service. Such design will let Crown act as a distributed blockchain cloud platform.
The next figure shows different components of Crown Platform Core.
Crown Registry Subsystem
To become a part of the Crown ecosystem, an application service must be registered in with Crown. In order to do this the Crown Platform provides cryptographic registration infrastructure. It allows not only a way to build a set of application services but also creates an opportunity to build other sets with common properties. Each of these set members becomes a part of the Crown blockchain and hence, cannot be removed from the history or modified without permissions of the set member owner(s). These sets can be named blockchain registries or just simply registries. The set members are registry entries or records. Crown Platform provides an opportunity to build Application Services Registry, Identities Registry, Titles Registry etc.
The registries architecture is the natural development of the Skeleton Keys ideas described in the Introduction & Features Crown paper. Each registry entry can be identified by a hash. It may also contain other information associated with a hash, like name and metadata. The most important part in building registries is hash preimage. It can be a public key or a contract in any jurisdiction, or almost anything else that needs to be registered in the blockchain. The real power of this mechanism appears when hash preimage is a public key. It creates an opportunity to create associative public keys model which can be utilized to build a decentralized public key infrastructure (DPKI) in the future. The public keys registered on the blockchain can be represented as Crown addresses, but to differentiate them from the original ones, they should have a special prefix that represents their belonging to that registry. To distinguish one address type from another it’s important to introduce two notions: Crown Payment Address and Crown Registration Address. Crown Payment Address — is an ordinary Crown address. Crown Registration Address — is a registered hash of a public key (Crown Public Key). It can also receive payments as an ordinary address, but it’s not encouraged if there is no logical reason for that.
Registration
Registration is a two-step process which includes publication and verification/approval of a new entity. Anyone can publish a new entry into a registry, e.g. an application service. At this stage, the entry is published but not verified yet. It becomes a part of a pool of the published entities, e.g. if a new identity is being registered, it appears in the pool of new identities. Nobody should trust that identity yet because it has not been verified. The verification in Crown Platform is performed by a quorum of the agents empowered by the Crown Network.
Actors
In the registry subsystem, there are four main types of actors: registrants, agents, eligible voters and consumers. Each of these roles is important and creates an n-tier system of interaction between the actors to ensure the registered entities are authentic and conscientious.
Crown Registrant — is an entity (usually person or company) who publishes, updates and removes its entry in/from one of the Crown Platform registries, e.g. Application Service Registrant — is an entity who wants to publish its application service in the Crown blockchain. Authenticity and validity of the registrants are verified by the agents.
Crown Agent — is a verified registrant which is empowered by Crown Decentralized Governance Proposal System (CDGP) to perform some useful work for the Crown ecosystem. Usually, it’s verification, licensing or another process to approve or empower other registrants. E.g. Crown Identity Verification Agent is an entity which has right to verify and approve new identity registrants. But other types of useful work are also possible. To become an agent, a registrant must be empowered by the Crown Network via CDGP.
Agents can be non-profit organizations which are supported by Crown Budget or profitable businesses who take payment for their work in the Crown ecosystem or both.
So, in the normal case, becoming a Crown Agent is a two-step process. It includes registration plus voting which empowers or rejects an agent candidature.
It’s possible but not encouraged to empower agents with different permissions. The concentration of power is undesirable.
Crown Eligible Voter — is an actor who has a right to vote for or against empowering an agent candidate, verify a registrant (if necessary), or vote about another decision in the Crown ecosystem. To be eligible voter one must prove ownership of a defined amount of tokens. Masternode Operators are eligible voters. Systemnodes will become eligible voters too.
Crown Registry Consumer — is a class of actors who interact with the Crown registry subsystem from outside of the registration lifecycle. The consumers can trust identity owners based on the information from the registry, or make sure that a legal contract has been signed by two or more entities. The user of an application service can pay for providing services etc.
Decentralized Public Key Infrastructure
One of the most important things about building registries using public keys is utilizing their cryptographic nature. Any of the agents who are empowered to do some job in the network can convey their will by signing a transaction in the blockchain. In the common case when a registrant publishes a new public key entity to be verified by the agents, it needs to assign it to specific agents. After the verification process, the agents express their decision by signing the entry in the registry. If the quorum has been reached, the entity is considered verified and it can be trusted by other parties. The owner of the registry entry is usually also a part of the quorum. It’s used for proving ownership of the entity, initiate and verify modifications, and have the opportunity to initiate deregistration process. The quorum needed for approval is defined by a multisignature N-of-M. The higher the N number the more decentralized decision is. In the real world though it’s necessary to find a trade-off between ultimate decentralization and a sufficient number of agents.The starting point could be 3-of-5 multisignature and 2-of-3 for the testing period.
Another separate use case is when a registrant publishes a new entity and assigns it just to itself. To verify that publication, only the signature of the registry entry owner is necessary. An entity registered that way should not be trusted by other parties unless that entity is an empowered agent. It can be used for testing purposes or for agent registration. It can be thought of like a self-signed certificate in a classic public key infrastructure.
It’s important to note that a registry entry owner and a publisher can be different entities. Anyone can publish a new entity and assign it to someone. But only after the verification process can it be considered authentic and valid.
Entities with common properties can compose registries where public keys are used to identify and prove ownership of these entities. Other cryptographic properties can also be utilized in different ways. As mentioned earlier, it’s possible to create an associative model of public keys based on cryptographic registration infrastructure. A public key from one registry can be associated with a key from another one in order to build a PKI without central authorities. Instead, a decentralized mechanism is used where a key to be trusted needs to be signed by a defined number of the agents, who in its turn are empowered and certified by the whole Crown Network. The agents’ public keys can be thought of as root certificates in classic PKI, but they cannot certify other keys in isolation from other agents. It’s important to note here that agents are usually empowered to certify only a specific class of registrants’ public keys — the keys from one registry. It’s possible to assign rights to sign keys from multiple registries, but the concentration of power of the same agents is not encouraged. It can be used in the beginning though when the network of the agents is not big enough.
For example, Identities Registry can be constructed by registering public keys and identity metadata associated with it. They are verified by a defined number of the agents. It creates a layer for building PKI trees where certified identity keys act as root keys. Public keys from other registries can be associated with identities, e.g. application service can be published as a child key to an identity key. To be verified the service key must be signed by the identity and agents empowered for application verification. It creates a structure where entities from different registries can be certified in a decentralized way and compose a tree where a person or a business can always be identified and proved by cryptographic mechanisms. It constructs a good foundation and infrastructure for transparent, lawful and secure operations for businesses on top of blockchain technology.
The next picture shows relationships between keys in the Crown registration transactions in order to build DPKI.
Crown Opcodes are building blocks of cryptographic registration infrastructure. They are used in the creation of registration transactions.
Registry Deposit Model
In order to create a new record in one of the Crown Platform registries, a publisher must make a deposit in Crown tokens (CRW). The deposit must be sent to a multisignature address or another Crown address which will be the owner of the new registry entry. The deposit also can be named — a locked amount of the tokens. It must never go lower than the defined number during the registry entry lifetime. Value of the locked tokens should be specified for each registry. If the amount is too small, the registry transaction will be rejected. The deposit must be high enough to prevent the system from bad actors and DDoS attacks, but not too big to be unaffordable for consumers. It can be released anytime when the owner does not need the registered entry in the blockchain anymore and sent to any address. The entry will stay in the history, but won’t be active. The registries architecture provides an ability for the agents to revoke registered keys and deregister other hashes, if their owners start behaving dishonestly. During the revocation process, they also withdraw the deposit from the locked address and distribute it between agents’ addresses. It has two implications. First: a publisher will lose the deposit if he/she is trying to register malicious/”bad” entry (e.g. fake identity). An attacker knows that and won’t publish knowingly invalid/fake data because his financial assets will be forfeited. And second: this model incentivizes verification agents to deliberately check published entities (e.g. identities, application services etc.) for intentionally or unintentionally invalid data. If the registrant’s entity is malicious (e.g. fake identity, malicious application service etc.) it will be rejected and the locked CRW will be withdrawn to the agents’ addresses for their efforts (they also can be incentivized by the Crown budget and verification fees, so there are different business models that can attract businesses to become Crown Platform agents). If a registrant puts invalid data into a registry accidentally, it can be fixed by the owner and re-verified by the agents. The revocation/deregistration can be performed at any stage of a registry entry lifecycle.
Another possible DDoS attack vector (flood attack) is a massive generation of publication and deregistration transactions without a heavy financial loss for the adversary. If he/she holds big enough amount of Crown tokens, it’s possible to send many spamming transactions at the same time with a minimum transaction fee. The deposits can be locked, unlocked and then reused in another spamming round. Even though, presumably, the attacker will run out of money sooner or later and “good” transactions will be prioritized by time to be included in a block, it makes sense to add another protection level. The solution is to raise transaction fee that it is affordable for “good” users and a crucial loss for the adversary. The fee can be 10% of the deposit amount for the publication and deregistration transactions and can be distributed between the verification agents. This is a low fee for a registrant who wants to register one or several entities, but it will kill any DDoS attack.
For example, it is unlikely that one entity (e.g. individual or business) will need to register more than one identity. Let’s say the deposit for such registry is set to 100 CRW. This is a small amount for one registration, but it’s a big number for an adversary to perform a DDoS attack or try to publish fake identities. 10% of this deposit is 10 CRW on the publication and 10 CRW on the deregistration stage. Every individual or business can afford to pay this one time fee, but an attacker will run out of tokens very fast. In this case, a publisher must deposit at least 110 CRW. Eventually, in a normal workflow, a registrant will get 90 CRW back.
This deposit model also will make registrants release locked tokens if they don’t use the registered entity anymore, but at the same time, they won’t deregister it without a good reason because of the high transaction fee. It will help keeping registered entities active in the system which are really in use and help to deactivate unused entities which just wastes computational resources.
Access to this infrastructure is provided to application developers via the Crown Platform API.
Crown Governance Evolution (Agents)
In order to build a decentralized registry system where agents are empowered to accept or reject new registrants, the CDGP must be extended. Currently, it only supports proposals for budget distribution. The goal is to create a governance system where different types of proposals regarding the future of the Crown platform and its ecosystem can be posted. One of the most important mechanisms which should be a part of the CDGP is assigning roles to different entities (agents empowering).
As mentioned in the actors’ section, it’s possible that the system does not have a quorum of the agents to approve a registrant. In this case, responsibility for an agent identity verification before empowering is also a part of work for the eligible voters. It means that in some situations an agent role can be assigned to a not verified registrant. Strictly speaking, the process of empowering, for both cases, is not really different for the eligible voters. It’s a very responsible step to assign a role to someone in the Crown ecosystem. If an entity applies to become an Identity Verification Agent, it will have access to personal data of registrants. That’s why all eligible voters must check agents deliberately before assigning such a role to them. Any voter can request information from an agent and verify this information inside and outside of the blockchain.
Thank you for your attention. More details will follow soon about other Crown Platform subsystems, how we are going to integrate Turing-complete smart contracts and more. Feel free to read and comment the full document containing more technical details.
