Technology

Architecture

RIFOS is a set of protocols that help user applications consume decentralized services. Protocols are implemented by service providers, which can serve user applications and also other service providers. There is no inherent RIFOS protocol hierarchy, but a protocol hierarchy materializes for each specific distributed application. In other words, some protocols can be “support protocols” of other service providers in some applications or provide the main functionality in some other distributed applications. The more protocols RIFOS integrates, the greater the benefit for the developer.

RIFOS is aimed at making the deployment of applications using distributed blockchain technology much easier and faster, without the need to provision any infrastructure services ahead of time. So, for instance, a wallet may grow from being a lightweight, SPV-mode application with very low storage and bandwidth requirements, to a full-blown multi-currency wallet, connecting to or running several full nodes consuming gigabytes of storage and bandwidth, without updating a single line of code. The change in functionality can be accomplished by changing the service providers. RIFOS is envisioned to enable a marketplace that can satisfy growing demands. Developers can integrate their RIF-compatible products and services seamlessly within the RIFOS ecosystem.

RIFOS services may be run by anyone. At the center of RIFOS is a utility token called the RIF Token. The RIF Token is managed by a smart contract running on the RSK Smart Protocol. Although RIFOS protocols do not obey a hierarchical structure, when considering RIFOS together with RSK and Bitcoin, RIFOS becomes a multi-layered development stack.

D1 refers to the RIF Naming Service that is deployed in the RSK blockchain.

RIFOS Core components

One key feature of the RIFOS design is that it accepts third-party service providers for the existing infrastructure protocols. Furthermore, new infrastructure protocols may be added in the future, either by RIF Labs or by any member of the RIFOS community, in order to enhance this open standard framework and offer greater functionality to the RIFOS user base. Any RIFOS component that conforms to the RIFOS design principles should be able to seamlessly interoperate with other components, draw on resources available within the ecosystem and compete fairly for users and businesses.

RIF Labs will initially deploy the following RIFOS protocols (also called “core components”):

- RIF Payments: A protocol to access any off-chain payment network, specially payment-channel based networks. This protocol should enable scalable, cheap and high-speed off-chain payments; RIF Payments enables the use of different off-chain payment networks that can be deployed on top of RSK, supporting both smart bitcoins and standard fungible tokens. The protocol provides methods with clear semantics to enable a uniform interaction between the user, a hypothetical RIF-compatible wallet, and distinct payments networks. The RIF Payments API can help build bridges between different networks. The open-source, open-provider nature of the API enables new networks to advertise their services using the RIF Directory Protocol. Each payment network gets a distinct address namespace so that addresses are always unique. By using the RIF API, services like Point-of-Sale gateways (PoS) can be built, and these PoS services can work across all existing and future RIF-integrated payment networks. The end goal of the RIF Payments protocol is to generate a competitive environment where payment networks can flourish to provide low fees and low latency, and that can scale to match the volume and exceed the performance of legacy credit card networks. RIF Payments also proposes a conceptual framework that is intuitive and relies on legacy concepts such as savings accounts, checking accounts and term deposits.

- RIF Directory: An alias system (Naming Services) protocol enabling name actions and 2nd markets. RIF Lab team believes that cryptocurrencies will grow exponentially in the next decade. However, to genuinely enable mass adoption, not only by the tech-savvy community, anyone needs to be able to manage digital wallets and assets. So, one of the principal barriers to adoption is the inherent complexity of the blockchain technology. Ease of use is key for reaching the unbanked and non-technical users. It’s difficult to expect a widespread adoption if users must copy and paste long hexadecimal addresses to transfer or receive digital assets, for example. In addition, manually typing addresses is an error-prone process, and a simple typo may result in a loss of funds. By adding a name resolution service, also known as “aliases” or “domains,” the probability of errors is greatly reduced, as is the apparent complexity of the system: the easier the technology is to use, the faster the adoption. The RIF Directory goal is to find different types of resources by simple resource names. Example resources are: RSK addresses, personal encryption public keys, social network handles, and so forth. In addition, centralizing the access to multiple resources associated with a human-readable name improves the RSK platform user experience. RIF Directory can also allow non-for-profit organizations to add transparency to their treasury management by publicly disclosing their names in the public addresses. As resource names may change over time, the system needs to be flexible to support frequent changes. Lastly, the system enables users to easily buy, sell and auction names, using the RIF token.

- RIF Secure Communications: Peer Discovery protocol for authenticated and encrypted communications. RIF Secure Communications Infrastructure (RSCI) is a protocol to enable parties that need to communicate to register their communication methods, discover other parties and contact them through their preferred communication method by using their public keys as a discovering mechanism. By using the protocol, Alice may publish her pseudonym on the RIF Directory, along with her communication’s public key. Whenever she uses her alias to establish a connection, the counterparty can look up her communication’s public key, and use it to create a secure connection, enabling pseudonymous communication among participants. RSCI aims to fulfill the need for establishing secure communication links between RIFOS parties or services. These communication links should at least assure confidentiality, integrity, and authenticity. On top of the properties mentioned above, it is possible to build additional features, such as group communications, non-repudiation, and forward secrecy.

- RIF Storage: Decentralized redundant data storage access protocol. The RIF Data Storage Layer (RDSL), is a protocol acting as a connectivity layer for third-party storage providers. This protocol introduces concepts to enable the seamless transfer of data and negotiation of prices between storage providers and clients over the RSK blockchain. The open-source, open-provider nature of the protocol allows for new networks to advertise their services on the RIF Directory. Most people take for granted the ability to store personal data reliably. Distributed storage networks are intended to afford anyone in the world with an internet connection, regardless of location or means, the ability to store their digital identity, resources, and sensitive information, with the confidence that their data is cryptographically secure and private. RIF Data Storage Layer enables different third-party storage networks to coexist and compete, so each storage network registered in the RIF Data Storage Layer gets a distinct address namespace so that addresses will always be unique. Using the RIF API, it will be possible to build compatible services that work across all storage networks. The end goal of the RIF Data Storage Layer is to enable a competitive environment where storage networks can thrive to provide scalable storage solutions with low fees and low latency, while allowing the users to store their critical ID information encrypted in distributed servers around the globe.

- RIF Data Gateways: Oracle protocol to access external data feeds. Blockchain protocols with on-chain smart-contracts must communicate with external systems through oracles. The RIF Data Gateways Service provides an implementation-agnostic protocol for external data consumption through Data Service Providers. Some examples of external data that frequently needs to be consumed by smart contracts are price feeds, and the state of foreign blockchains. Securely notifying contracts about the state of foreign transactions makes it possible to transfer tokens by building bridges between blockchains.

- RIF Explorer: Explores the services registered for every component of the RIFOS. The RIFOS Platform provides a set of abstractions and APIs to support third-party implementations in the form of RIFOS Service Providers. This decoupling enables the platform to switch to new, potentially more enhanced implementations as the technology of each service evolves, and new solutions emerge. In this context, it is necessary to provide mechanisms to register and discover these implementations allowing developers and clients to choose which one they want to use for their particular use cases. RIF Explorer is a service of the RIFOS Platform that provides the required functionality to register and discover third-party implementations of the RIFOS Services (aka Service Providers) in the RIFOS Platform. RIF Explorer extends the RIF Naming Service (RNS) capabilities to support the recovery of Service Providers’ addresses not only by domain name but also by different criteria, such as service type or optional meta-data.

Source

A RIF Directory Implementation

RIF Labs has implemented a first service provider for the RDP, called RIF Name Services. RNS uses the RSK blockchain to maintain and control access to the name information. Therefore, RNS ensures the decentralization and security of the RSK blockchain. Although other RDP service providers may register in the future, RIF Lab team thinks that naming is inherently a service that greatly benefits from network effects, and therefore RIF Labs expect a single provider to be chosen by the RIF and RSK community in the long run.

The Design of RIF Directory Protocol

The RIF Directory Protocol defines an interface to simplify the use of addresses. This is essential to implement a mechanism which maps a user-friendly domain name to a resource (e.g. an RSK address). The system should be transparent: users should be able to attest that they own a certain domain, that they’ve paid the required fees, and the expiration date is clear so they can make payments in advance to reduce the risk of accidental loss of name rights. Also the design should consider the frequent case which different users want to acquire the same domain name, and try to resolve this before the name is acquired, avoiding costly dispute resolution stages. Last, the design should minimize the risk of name censorship and name squatting. Important to the design of RIF Directory Protocol is the RIF token, which is the preferred token for first-time name acquisition. The RIF Token is used as a mean to stake tokens at name auctions and also for paying a name’s maintenance rent.

Acquiring Domains

The Domain name database is interpreted as a tree. The root of the tree (called Root node) has control of all possible top-level domain names, or TLDs. The children of the TLDs are called Domains. In addition, children of Domains are called subdomains.

Any RDP name must conform to the following format: “subdomain(n)….subdomain(1).domain.tld”. Names consist of a series of labels separated by dots. The last label corresponds to the TLD, and childs always precede parents. Moreover, each label must be a valid normalized label as described in UTS46 with the the following restrictions: transitional must be false and use STD3AsciiRules must be true.

Obtaining a Domain by Blind Auctions

The mechanism to obtain a domain for the first time is through a blind Vickrey auction. “A Vickrey auction is a type of sealed-bid auction. Bidders submit written bids without knowing the bid of the other people in the auction. The highest bidder wins but the price paid is the second-highest bid”. The practice has shown that human psychological quirks and not just supply and demand drive auctions. Vickrey auction mechanism reduces the likelihood that a bidder will overpay for an item as well as it also increases the likelihood that the seller will get the most he can get for it.

For example, if “.rif” is the TLD and a user Alice wants to get the domain “alice.rif” (as shown in the previous figure), she can open an auction to this domain, make a bid, and if her bid turns out to be the highest, she will become the new owner of the “alice.rif” domain.

Obtaining a Domain by Delegation

A domain owner can delegate subdomain’s ownership to a buyer without going through an auction process. For example, if a user Bob is the owner of “bob.rif” and Alice wants the subdomain “alice.bob.rif”, Bob can delegate the subdomain ownership to Alice without an auction process. From the domain level perspective, delegation can be executed through a transfer of ownership. Once Alice gets a domain, she should set a resolver that will make the resolution between the new domain and the desired resource.

Domains Address Resolution

The resolution of a domain is the process where the system looks up the name in the database, checks if it present, and, if so, returns the associated information. This resolution can be used in wallets, exchanges or dApps, to handle user-friendly names instead of complex addresses. For example, for Alice to send money to Bob, Bob first sends his registered alias to Alice, and then Alice can lookup Bob’s address, by typing the alias in the wallet application, and the wallet will look up this name in the RDP database and proceed by using the address information obtained by the Resolver associated with the alias.

Secondary Markets

While RIF Directory does not specify a particular secondary market to be used to sell domains once they have been acquired, there are already decentralized second market solutions for people to buy and sell them. If the demand is high, RIF Lab expects the RIF community to create new secondary markets specifically tailored for domain sells. Secondary markets may accept paying for domains with other cryptocurrencies, and also they may support other kinds of auctions, or simple first-in first served transfers. Secondary markets for domain names may use also the RIF token, but are not limited to use only the token.

Service Provider’s Revenues

Service Providers may collect fees from name auctions and rents. They may choose to either burn the fees, donate them, or use them for profit. The RIF token fees also serve to prevent name squatting, because owners must pay an annual maintenance rent for every domain acquired.

Locked Tokens

When a user participates in an auction, the RIF tokens offered are locked in the Deed as shown in the following diagram. A part of the winning offer, corresponding to the amount of the second winning offer, is locked in exchange for the domain ownership. The other amounts locked corresponding to losing bids are refunded to their rightful owners on request. The RIF locked tokens will be refunded to the owner when the domain is released, minus fees that are defined by Service Providers.

Annual Payments

To obtain and retain ownership of the domain, an owner must pay a recurrent annual fee called rent. After nine months from the last annual rent paid, the domain owner will have the option to pay for the fee to keep ownership for another year or relinquish ownership over the domain. If the owner doesn’t pay the annual rent, it means the owner is opting to relinquish ownership, in this case his originally locked tokens will be returned to the user, minus a fee defined by the Service Provider

Source