Difference between revisions of "Main Page"
|Line 218:||Line 218:|
[https://ubix.wiki/index.php/Swap_SNTR_to_UBX Swap SNTR to UBX]
[https://ubix.wiki/index.php/Swap_SNTR_to_UBX Swap SNTR to UBX]
[https://ubix.wiki/index.php/Wrap_UBX_to_ERC20_UBX_token Wrap UBX to ERC20 UBX token]
[https://ubix.wiki/index.php/Wrap_UBX_to_ERC20_UBX_token Wrap UBX to ERC20 UBX token
[[Launch a Masternode]]
[[Launch a Masternode]]
Revision as of 18:07, 10 January 2021
UBIX.Network is an open ecosystem designed to integrate decentralized applications into a cohesive whole. To solve the integration problem, the following solutions were used:
1. The original decentralized protocol UBIX ((DAG), consisting of blockchains of various types) has been developed and is used to exchange sensitive data (master data) between applications.
2. The Ubikiri super application interface built on microservices is used to exchange data between applications through the internal API.
3. A legal solution that allows users to legally determine the legal relationship arising between users and node holders. The legal framework is based on the original UBIX license designed for decentralized applications.
For the development of applications, the UBIX launchpad platform is used, which is integrated into the UBIKIRI interface. A special approach called fair-ICO (fICO) is used to finance internal projects. The first internal fICO project was the internal UBIX.Exchange.
For the exchange of values within the platform, the native UBX cryptocurrency has been released. To regulate the money supply, monetary approaches are used with the use of public reserve and emission funds. In addition to UBX, tokens issued by various projects are used. For economic integration with external ecosystems (primarily with Ethereum), Crypto depository receipts are widely used both for UBX and for tokens issued on the platform.
A wiki system operated by the UBIX community is used to describe the entire project.
In 2017, the SilentNotary project was launched - a system for providing evidence with hashes recording into various blockchains using a wide range of interfaces.
In 2018, when conducting a legal study, the fundamental problem of using public blockchains was revealed - the interruption of the chain of legal relations when using anonymous nodes that process transactions. This leads to the need to develop a special technical and legal expertise at each trial to prove the stability of the used blockchain in a given period of time. At the same time, the fact of intervention and rewriting of the block chain (51% attack) leads to the compromise of all previous records.
Initially, the project appeared as a solution to the problem of fixing evidence on the public blockchain. At the start of the project, it was planned to upgrade the DAG of the Bytebal project (now called Obyte) with a redevelopment of the mechanism for selecting 'witnesses'. Subsequently, the idea of being able to choose your own groups of 'witnesses' led to the concept of the UBIX protocol and the development of a completely original protocol without any forks.
On June 16, 2019 at 00:29:21, the genesis block of the UBIX protocol was created, in which a consensus algorithm was defined for processing cryptocurrency transactions with UBX coins. Genesis block hash:8b6d259ee3ee1acd524654d9b27286188c982e3764f1ef3f6db98c6382e6d777
Project names and rebranding.
Since the project was originally planned as a blockchain for legaltech, the name "Chain-in-Law" was chosen, as a play on words with the designation of a legally arising relationship with the block chain. For this reason, the ticker LAW was chosen for the main currency of the platform. However, later, when rethinking the protocol's capabilities and developing the ability for users to create their own blockchains, including public ones with anonymous nodes, the name was changed to "Integrated Distributed Ledgers". Later, when choosing a name for the super application / interface, the name "Ubikiri", formed from the name of the Japanese ritual of swearing on the little fingers, won. When solving the problem of bringing all products and developments to a single brand, it was decided to use the abbreviation for Ubikiri. This is how the name UBIX appeared. The abbreviation UBX was chosen for the ticker of the protocol cryptocurrency.
To implement the possibility of creating integrated blockchains, the following approach was used:
1. Users can create their own blockchains (in terms of the Platform - Consiliums).
2. Each transaction has a special label that defines which Consilium can process it.
3. When the conditions defined by the Consilium Rules appear, Consilium is activated and the transactions accumulated in the mempool related to this Consilium are processed.
4. The block created by Consilium goes to the general distributed ledger, where the blocks are connected to each other in a Merkle tree, forming a directed acyclic graph (DAG).
Our civilization is built upon the law — a complex system of norms governing the behavior of individuals. This complex construction was built to get us a sustainable structure (namely society) consisting of unreliable components — the people.
Thousands of years since the first legal relations emerged, a similar problem was solved by building a reliable system for unreliable elements called the Blockchain Technology.
In the real world relations of the subjects lead to the creation of legal relations governed by certain rules — the norms of law. Legal relations and their changes can be represented as structures that can be grouped as directed acyclic graphs. The passage of time sets a(n) "orientation" (vector) and "acyclicity" of relationships: since one arises, it is valid until changed or terminated by a new relationship. Recognizing the right as absent would not erase it from the history but influence the future consequences.
For the emergence of a legal relationship, it is necessary to have legally defined subjects and a legal composition — the required aggregation of legal facts, i.e. legally significant actions and events with which the rule of law or the terms of the contract link the emergence of legal relations. At the same time, the key element of a legally significant action is the will of the subject of the legal relationship. It must be unequivocally interpreted action of the subject and have the direction of the emergence (change or termination) of the relationship.
The development of cryptography and the widespread introduction of asymmetric ciphers into practice allowed us to legally identify a subject and determine the fact of his will through the use of his private key. Usage of time synchronization between all network nodes allowed to reliably determine the corresponding point in time.
Today technologies let us build a universal cryptoplatform incorporated in the existing legal system, which allows users to enter into various legal relationships as easily as possible while simultaneously capturing them in the form of permanent records in a distributed registry.
To build such a platform, we only need to determine the legality of actions for a unit (node) of the network. As we tried to find the most common solution, we divided the classical consensus of the distributed registry into two levels — at the application level (user-defined transaction processing and block building) and at the network level, which ensures the stability and integrity of the network. Thus, users can independently determine the composition of the nodes, the rules for joining new nodes, and the order of processing transactions. This allowed us to create a tool for constructing legally defined procedures for servicing a wide class of business processes.
Network status and legality
Let us illustrate the description of the legal relations in more detail
As we previously postulated, the main function of the system is the creation, modification and termination of legal relations between users of the system with simultaneous fixation in the form of permanent entries in the distributed registry. Creating legal relations is possible as a result of the Entity’s active actions when using the Platform.
We consider the relationship as a process of occurrence of the rights and obligations of the subjects of the relationship regarding the object of the relationship in accordance with the norms of law governing these relations.
As an abstract concept, a process has an entrance space, a state change, and an exit space.
Diagram: the process of the legal relations occurrence
The input space includes Entities (not yet entered into a legal relations), objects (not yet involved in this legal relations), legal norms regulating the order of occurrence of this legal relations, Entity’s Will - parties to the legal relations, various environmental parameters (system environment).
A change (in terms of a process) is the content of a legal relations — a change in the Entity’s rights and obligations in the legal relations.
The output is the Entity’s subjective rights and obligations regarding the objects of law. Of course, formally, the output also includes Entities (with new rights and obligations) and objects (which became the object of a relationship, for example, those that have become the subject of a transaction).
Outputs of one process can be inputs of other processes, forming a network of processes or, in our case, a network of legal relations. Since we are dealing with completed processes (and time is irreversible), this network is directed towards past processes and is a directed acyclic graph.
Diagram: legal relations network (acyclic graph).
At the same time, if a legal relationship is built on the basis of already existing legal relations, then it uses the unspent outputs of this legal relationship allowed for use, which is very close to the UTXO model.
The exchange of User information with network units – nodes, occurs through transactions. The transaction contains a witnessGroupId field that defines the Rules to which the User (the sender of the transaction) joins and in accordance with which its transaction must be processed. When a transaction enters the network, it begins to spread across the network, passing from node to node. A number of transactions form a mempool – a temporary depository of transactions. Upon the occurrence of the conditions specified in the Rules, the group of Validators that have joined the Rules (nodes implementing the algorithmic part of the Rules, also called the Consilium), selects the transactions that they must process and form a block. After the transaction has been confirmed (included in the block), it is removed from the memory. Next, the block falls into the general network storage, built on the principle of a directed acyclic graph. The blocks are connected in accordance with the rules of Meta-consensus (the network level of consensus of the Platform distributed registry), which ensures the integrity of the network.
The platform is divided into three layers. Each of the layers can be reworked without affecting other layers.
Technical description of the platform.
Main modules of the platform business logic
In addition to the development of the Platform and interfaces, we are developing a number of versatile solutions representing the implementation of the most frequently used business processes. These are lego blocks (or a library of models) from which various business solutions can be constructed. The first pre-built modules are:
Personal Identification Module (KYC) Identification or authentication is a necessary part of almost any service.
The KYC module has several functions:
- Service and identification (ID Verification Operations): login, load of identifying data, calculation of hash, record of transaction with reference to identifiable subject. It is executed by a SilentNotary interface.
- Identity verification: search by ID hash, search by ID subject, ID verification (hash calculation and comparison with record), verification subject (decoding his true identity), search for existing black-list (records of unreliable persons), and search for compromised keys that will be implemented in Network Explorer.
For the identification procedure the User is able to determine the nodes that process these transactions. This allows geo-referencing of a node group to meet the requirements of the legislation on handling personal data (e.g. GDPR).
Token is a digital ID of objects that may be involved in a relationship in the real world (including intangible values such as IP). Token is a specific construct, the meaning of which is created by users by entering into various agreements. These agreements should take into account the requirements of the Transaction Processing Rules or be fully contained in such Rules.
As an example, a token can be used to represent a vehicle. A car's token is issued by its manufacturer with the production of a real car. Blockchain nodes that handle token smart contract identify the manufacturer and include a network of authorized dealers and authorized service centers. This car token enables the tracking of the entire history of the car:a change of ownership, maintenance, repairs, insurance, etc.
Currently tokenization of various types of objects is being developed. For example: cars, objects of art and historical value, licenses for aquatic farming. The Token creation process is facilitated as much as possible. The process was divided into two smart contracts — the registry-contract and the token contract. Thus, the user token is created using the register-contract while simultaneously classifying a token in the unified registry of tokens. During the token's life cycle, the user can assign additional features and properties, based on the changing needs.
The main purpose of the classification is to build a registry of all things. This problem is solved by constructing a polyfactor structure:
Let X be the set of all objects. Classifying means a partition of the set on any basis (i.e. – all warm-blooded animals or not, in this case the partition is on the grounds of "warm-blooded"). We will use the operation Boolean B ( X ) – as sets of all subsets of the original set X (i.e., the elements of B ( X ) are subsets). Then sets of partitions S is contained in B ( x ):
In this case, we require the execution of two axioms from splits:
It was argued that a plurality of partitions corresponds to a plurality of attributes. Here is an example graphical representation:
The prior set X consist of several objects
These elements of the partition we will call classes. You can enter the concept of nested partitions into subdivisions, partitions of independent classes of the original partition.
Thus, we create a set consisting of a plurality of elements of the source, the so-called factor set.
We often do this procedure at the household level, for example, if the initial set is a set of people, then the set factor can consist of two elements, men and women.
Further we will carry out a splitting of the Factor-Sets.
Factor partition-set is not the original object’s partitioning but the partition classes of the original objects. You can repeat this procedure several times by moving to the next factor-level until one element remains:
The resulting structure is called a factor structure. It is possible to build a structure factor by any other indication such as the initial partition We are going to do – build another factor.
A set of these structures is called a polyfactor structure. We can establish relationships between the elements of these structures; when these relations can include several structures,
then we can talk about polyfactorial relations. The task of creating the token is the task of building the appropriate multifactor relationships. This design is descriptive for all the possible diversity of the empirical world.
The voting module
In the course of the implementation of business, processes often need to quickly get feedback from a large number of users, and to do so in a legally meaningful way. It may be a decision to shift, let’s say, the management company of the investment fund unit holders, the meeting of creditors of the borrower, or just any elections—a representative of a group of people to delegate their interests.
Economic Model of the UBX
Cryptocurrency remains one of the most used term when talking about DLTs, however, the meaning of this term remains elusive. For some, it is the means of payment, for others it is an interesting technology solution or a platform for implementation of their services. As a rule, there is no one explicit cryptocurrency, it is usually combines all designated opportunities, but in different degree. For example, the most popular cryptocurrency for payment is Bitcoin, one of the interesting technologies is Byteball, while the most popular cryptocurrency for implementation of services is Ethereum. However, despite these differences, we consider that it is possible to introduce a concept of Economy with respect to each such currency, relying on basic economic principles when developing each of them.
The theory underlying any cryptocurrency is a theory of money, an economic theory studying influence of money on economic system. When speaking about the economic system, we mean
aggregate economic processes within the ecosystem that has emerged with regard to this platform.
In the course of economic theory development, several economic theories of money have been developed - Nominalist theory, Monetarism, Keynesian theory of money, and Synthetic theory of money. From the theories listed, the theory of monetarism (Milton Friedman's Theory) is the most suitable one for crypto-economy at the current stage of its development, and for our case.
- Economy Ecosystem
- Organizational Structure of the UBX Consilium
- Regulation of Coin Economy
- Funding the UBX-coin Development
Our vision for the development direction of blockchain technology is to introduce network nodes into a legal space, dividing consensus into network and application levels and, as a result, creating an ecosystem of deeply integrated blockchains located in a single network - in a common space addresses and transactions. The future of technology is not in opposition to the existing order of things, but in integration into the legal system and its organic change from within.
We thank all our followers, our friends and colleagues who, with their advice, with their kind words, and with their hard work, have helped us to create a new blockchain platform that we believe will have an impact on the lives of an enormous number of people. The main part of our platform has already been developed and tested. The source code (Node . Js) is available on Github at: https://github.com/SilentNotaryEcosystem/Cil-core
We will be grateful for any contribution to the development of our platform and we are open to any advice and comments.
We also encourage developers interested in using our platform to contact our team for clarification. We will be happy to help you to integrate our blockchain into your project.