Accounts

COFFE Multichain allows you to create unique names up to 12 characters long without spaces as an account ID using lowercase letters a-z and numbers 1-5. Please note: the figures 0, 6, 7, 8, 9 cannot be used in account names. It is not necessary to replenish the account balance to ensure the possibility of storing data since this happens automatically during registration. In addition, for corporate users, account names can contain a pointer to the namespace while only the owner of the @domain account can create accounts of the @user.domain type. Such accounts are created for developers and corporate customers. For creating an @domain account, it is necessary to make a request to the email address team@coffe.io, with the organization indication and the project description.

In the context of decentralization, application developers will pay the nominal costs of creating accounts for their new users.

Actions and event handlers

Each account has the ability to send structured Actions to other accounts and can also define procedures for processing incoming Actions (scripts). COFFE Multichain allocates a secure database to each account which only the account's own event handlers have access to. Handlers can send Actions to other accounts. The combination of Actions and their automated handlers is the smart contracts in COFFE Multichain.

Role-based access rights

Access rights management includes determining whether Actions have access rights. The simplest form of access rights management is to check whether the transaction has the necessary signatures, but it assumes that the required signatures are already known. As a rule, access rights are tied to individual employees or groups of employees and are often divided into separate branches.

COFFE Multichain provides a declarative access rights management system that gives accounts detailed and high-quality control over actions.

It is very important that the management of authentication and access rights is standardized and separated. This makes it possible to create access rights management tools in a universal way, and it also provides ample opportunities for optimizing performance.

Each account can be managed by a combination of other accounts and private keys weighted by their shares. This creates a hierarchical management structure that reflects the actual organization of access rights and makes multi-user control easier than ever. Multi-user control by itself makes the greatest contribution to security and, if used correctly, can significantly reduce the risk of theft by hacking.

In COFFE Multichain allows accounts to create combinations of keys and/or other accounts that can send a certain type of Actions to other accounts. For example, there is a possibility of having one key for the user's social networks and another for accessing the stock exchange. It is even possible to transfer the access rights of one account to another to perform actions on its behalf without transferring the keys.

Named Access rights levels

COFFE Multichain accounts have the ability to set named levels of access rights with the ability to inherit permissions from a higher level (hierarchy of access rights). Each named access level defines an administration unit; such a unit is a multi-signature verification procedure with an indication of the action thresholds, keys, and/or named access levels of other accounts. For example, the "Friend" access level can be set for an account that can be controlled equally by the accounts of all the user's friends.

Another example is the Steem blockchain which has three named access rights levels fixed in the code: Owner, Active, and Posting.

  • Posting allows to perform only social actions such as voting and publishing records;
  • Active allows to do everything except change the owner;
  • Owner is worth storing on a cold storage carrier (not connected to the network) because it makes it possible to perform any actions with the account.

The COFFE Multichain software generalizes this approach, allowing each account owner to set their own hierarchy of access rights, as well as group actions.

Named groups of event handlers

COFFE Multichain provides each account with the ability to combine event handlers into hierarchical named groups. Such named handler groups can be used by other accounts during the configuration of their access level settings.

The upper-level event handlers are named by the account name and the lower ones - by the individual types of messages that the account receives. Such groups can be called as @accountname.groupa.subgroupb.MessageType.

This model allows the exchange contract to group the creation and cancellation of orders separately from deposits and withdrawals. Such grouping by an exchange contract is generally accepted for users of stock exchanges.

Binding access rights

COFFE Multichain allows each account to determine the correspondence between the contract/action or contract of any other account and their own named access level.

For example, the account owner can map the social network application of the account owner to the "Friend" permission group of the account owner. With this mapping, any friend can post messages as the account owner on the social networks of the account owner. Even though they will publish messages as the account owner, they will still use their own keys to sign Actions. This means that you can always determine which friends used the account and how.

Applying access rights

In the process of delivering an Action message from @Anna to @Alex, COFFE Multichain will first check whether @Anna has the appropriate access rights for @alex.groupa.subgroup.Action. If no match is found, the rights to @alex will be checked sequentially for @alex.groupa.subgroup, then @alex.groupa, and eventually, for @alex. If no matches are found, the named permission group @anna.active is assumed to be applied.

Once a match is found, the signature right is checked considering the multi-signature threshold and the named permission right. If the check fails, the parent permissions are checked up to the owner's access rights, @anna.owner.

Source groups of access rights

COFFE Multichain allows all accounts to have an "owners" group that can do everything and an "active" group that can do everything except change the owners group. All other permission groups are derived from "active".

Parallel assessment of access rights

The process of evaluating access rights is presented in the "read-only" mode and the rights are changed through transactions that take effect only after the block is formed. This means that all keys and the evaluation of access rights for all transactions can be performed in parallel. Moreover, it also makes it possible to check all access rights before launching the logic of the application itself, the results of which would have to be rolled back if access rights were violated. Finally, this approach allows to check the permissions of transactions not at the time of their application, but at the time of receipt.

Given the above, access rights verification takes a significant part of the overall transaction verification process. Parallelization and the inability to introduce changes makes the permission verification process much more productive.

In the process of reproducing the blockchain from the Actions logs in order to restore the status, there is no need to re-check access rights. The very fact that the transaction is included in a previously confirmed block is sufficient to skip the access rights verification stage. This significantly reduces the computational load associated with re-reproducing transactions of an ever-growing blockchain.

Actions with delayed delivery

Time is a critical component of security. In most cases, it is impossible to find out that the private key has been stolen until it is used. Time-based security becomes even more critical in cases where the application requires storing keys on computers connected to the network and used every day. COFFE Multichain allows application developers to apply certain Actions not at the time of inclusion in the block but with a certain set minimum delay. During such a forced delay, the Action can be canceled.

At the time of sending such Actions, users can receive notifications by e-mail or sms. If the Action was not authorized, the user can use the account recovery procedure and revoke such Action.

The delay time is determined by the importance of the operation contained in the Action. So, the payment for COFFE Multichain may not have a delay and be irreversible in a few seconds while the purchase of real estate may require 72 hours as a period for approval. It may take up to 30 days for the entire account to be transferred to someone else's control. The exact value of the delay time is set by the application developers and users.

Still need help? Get in touch!
Last updated on 31st Dec 2021