As you’ll be aware, Remme is migrating to the EOSIO framework, bringing with it a number of tech tasks that must be completed to give Remme Protocol, and REMChain in turn, its full functionality. We covered the architecture of the new-look Remme tech stack in our recent technical paper on the matter. Now we’d like to zero in on the smart contracts that will power the core services of Remme Protocol.
Smart contracts are an integral component of blockchain-based systems, enabling digital verification and enforcement of rules, which allows for transactions to be completed without the need for third parties. First proposed by Nick Szabo long before Bitcoin was even created, smart contracts have come to play an increasingly vital role in controlling a host of blockchain systems. From automating insurance payouts to facilitating cross-chain asset swaps, smart contracts are the invisible hand guiding much of the cryptoeconomy. In the future, entire industries, from law to credit loans, may be partially automated by smart contracts that eliminate the need for human input, and thus for human error.
In the here and now, though, system smart contracts (operated by Block Producers, regular users are not able to modify the state of a system contract) have a vital role to play in delivering information about the external state, controlling key functions of Remme Protocol and its supportive ecosystem. In this article we’ll examine some of the ways in which smart contracts interact with Remme Protocol components.
A quick primer on Remme Protocol
Our goal in conceiving Remme Protocol was to create a full-cycle identity and access management solution suited to humans and machines alike. In other words, a product that could be purposed for controlling staff access to company networks, but which was equally adept at verifying IoT devices connecting to the edge of the cloud. Remme Protocol provides a basis for establishing self-sovereign and authority-issued identities, with a broad array of use cases spanning multiple verticals, segments and industries.
At the heart of Remme Protocol is a flexible and future-ready solution that provides a robust and secure alternative to traditional PKI systems, which present a single point of failure. Some of the use cases we’ve envisaged for Remme Protocol – a number of which have already been successfully trialed during our pilot program – include user and smart devices authentication, digital key management, domain validation, email signing, and code signing.
Now let’s take a look at some system smart contracts that make all of this possible in Remme Protocol.
Foundational component #1: System contract for managing account attributes
Attribute-based access control (ABAC) is the system used to determine which access rights are granted to certain users. For example, senior management in a company would be expected to have broader access than junior staff. A properly functioning ABAC system will ensure that access policies are enforced properly at all times, so that privileged information is only accessible by those with the authorization to view it.
Attribute-based credentials are cryptographically secured carriers of properties that correspond with a particular user. They are a key component of numerous privacy-preserving solutions and identity management systems. When designing attribute-based credentials, however, there are certain limitations and requirements, aside from privacy and security, that must be taken into account – like usability and efficiency.
Attribute-based identity management has a wide range of tangible real-world use cases, both online and offline. Successfully implementing an ABAC-based solution, however, demands that certain credential design principles are met. Through effectively integrating attribute-based credential systems, useful identity relationships can be established and maintained.
Any account can start and host its independent namespace of attributes. However, there will be a predefined namespace with attributes delivered by the system smart contract rem.attr. Standard attributes will include basic Directory attributes like “Common Name”, “Organization Name”, “Picture”, and etc.
There are also several types of attributes based on the way they can be assigned to an account:
- Self-assigned - only the account that receives the attribute can issue it.
Examples: ComonName (UTFString), Picture (URLString or IPFS CID). - Public Pointer - any account can assign such attribute to any account.
Examples: FollowedBy (Remme Account Reference). - Public Confirmed Pointer - any account can assign such attribute to any account, however, the receiving account has to explicitly confirm it.
Examples: SomeTermsAndConditionsAcccepted (OID, URL, IPFS CID). - Private Pointer - attribute-namespace-owner account can assign such attribute to any account.
Examples: Door1234AccessGranted (Boolean). - Private Confirmed Pointer - attribute-namespace-owner account can assign such attribute to any account, however, the receiving account has to explicitly confirm it.
Examples: AgentKYCPassed (String:TierLevel).
Attribute naming starts with the account name that manages its namespace and followed by the attribute name, e.g. accountname:attributename.
For instance, the list of standard attributes of some account may return:
$remcli get account attributes rem.attr someaccount
rem.attr:commonname = "John Doe"
rem.attr:picture = "/ipfs/QmW2WQi7j6c7UgJTarActp7tDNikE4B2qXtFCfLPdsgaTQ/cat.jpg"
For instance, the list of standard attributes related to domain validation may return:
$remcli get account attributes rem.domain someaccount
rem.domain:commonname = "verified.domain.com"
rem.domain:commonname = "verified.domain2.info"
For instance, the list of assigned attributes of some account that belongs to XYZ Company may return:
$remcli get account attributes xyzcompany someaccount
xyzcompany:commonname = "John Smith"
xyzcompany:organizationalunit = "Head Office"
xyzcompany:picture = "/ipfs/QmW2WQi7j6c7UgJTarActp7tDNikE4B2qXtFCfLPdsgaTQ/cat.jpg"
Assigning any attribute sends a contract action to the receiving account, so the account contract (or a watching node) may react to this event. For example, an exchange may monitor a user account and react to an attribute assignment event by a trusted KYC agent (e.g kycagent:verified = "Tier1").
Foundational component #2: Verification of the external state by Block Producers
With REMChain being an independent blockchain fueled by the REM token, Remme Protocol utilizes the decentralized consensus algorithm Delegated Proof of Stake (DPoS). Under this algorithm, those who hold a certain amount of tokens on a blockchain adopting the protocol software may select Block Producers (BPs) through a continuous voting mechanism. Anyone who accumulates a minimum required amount of tokens may choose to participate in block producer election by running for top 21 status or vote for other candidates they trust and feel confident about.
With the elected Block Producers that negotiate and form the deterministic environment for the smart contracts that run on-chain, there is the second foundational component of the Protocol that is present to bring the information about the external world to the blockchain. This component is called External Validation and is a separate and parallel routine performed by the Block Producers. Such routines are implemented as a set of plugins for remme-node (or nodeos in eosio terms) or sometimes as an independent service that uses an independent key connected to the same account of a producer. Standby Block Producers should also participate in External Validation routines, and by doing so, demonstrate to the community their uptime, performance, and engagement to increase their social reputation.
BP verification of the external state works as follows: for each service within the Protocol ecosystem, there will be a requestor (account). With relatively difficult tasks (like Domain Name validation), the request is expected to be paid with REM tokens. The submitted request along with the object (a domain name, for instance) must also describe the expected result that BPs will be called upon to verify.
For example, an account (johndoeaccnt) may claim on-chain ownership of a domain (johndoe.com) following these steps:
- Create a file {$chain_id}.json in the root directory. E.g. http://johndoe.com/aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906.json
- Let the file content specify the on-chain owner account name. E.g.
{ owner: "johndoeaccnt" } - Execute a transaction that requests external verification.
All BPs (Active BPs mandatory, Standby BPs optional) will process the request, by fetching a URL and verifying ownership by comparing the requestor’s account name and the information returned by the webserver in the json file. Every BP will send a transaction with its resolution and signature. This will include the following data: request ID, the resolution (confirmed or failed), timestamp.
Every transaction with the BP resolution checks whether it’s passed the threshold of the Active BP majority requirement on a particular External Validation request. If yes, the request transition into the final state and there is a callback made to the requestor contract about the consolidated resolution. Depending on the case, an attribute may also be assigned, for example in the domain validation scenario: rem.domain:commonname = "johndoe.com". The External Validation request is always a timeboxed task so that if there is no consensus among BPs or the majority threshold is not met, the request will resolve with the failed status.
Conclusion
There’s more to cover in regards to the system smart contracts of the Remme Protocol ecosystem, but in this overview we’ve covered its two important components: Attributes management and External State validation routine. For more information on how these interact with Remme protocol, our technical paper has all the details. Understanding the Remme Protocol’s smart contract system is key to grasping the efficiency and security underpinning our full-cycle identity and access management solution.
.png)
