Nexus Contracts

Menu...

Existing Smart Contracts have experienced issues in relation to ease of use, security, and most importantly scalability. Addressing these issues, Nexus has developed a Register-based Contract Engine, with greater capabilities than other contracting engines. Unlike other blockchain designs, which tend to be defined by only two layers of processing and in some cases require unique coding languages, the Nexus Contract Engine is facilitated through seven individual layers of the Nexus Software Stack for specialized dedicated processing, and is easily accessible via APIs.

© Copyright 2019 Content by www.nexus.io

Smart Contracts

Smart Contracts are self-executing. Their design is to enforce the terms and conditions of a contract through programmable logic, reducing the need for third party intermediaries such as brokers and banks. Smart Contracts are an additional layer of processing above the ledger layer, (the blockchain) and are comparable to small computer programs that hold a state of information. The calculations of the contract are carried out by the processing nodes of a blockchain, which change the state of the information. Given that the calculations or processing is carried out by distributed consensus, the state of a Smart Contract is immutable.

Bitcoin was the first cryptocurrency with built-in Smart Contract capabilities, which it calls ‘scripts’. Scripts are not Turing complete and contain byte code. Ethereum augmented these capabilities into its ‘Turing Complete Smart Contracts’, which are generic to developers’ needs. Ethereum gives developers more access to contract functionality on a blockchain through a custom programming language called Solidity, which is then compiled into assembly language that is run on the Ethereum Virtual Machine (EVM). The EVM is a ‘Stack-based Virtual Machine’ that processes each instruction in turn.

Though very capable, Ethereum has experienced some issues in regards to security, performance, and ease-of-use, predominantly because of its Turing complete design. Some notable cases include the $75m DAO hack on Ethereum, and the $286m Parity bug. Vulnerabilities existed due to the large complexity of a Turing complete system, and the resulting difficulty of resolving bugs in a protocol written in immutable code. The complexity of operations that support universal computation or Turing complete designs also limit scalability. A universal system has a higher degree of complexity, and can not therefore compete with technology that is designed for more specialized tasks. An example of this observation would be the comparison between a CPU (Central Processing Unit) with a ASIC (Application Specific Integrated Circuit) in the mining of cryptocurrency. A CPU can’t compete against a SHA256 miner, as its complexity and design is geared to support universal general computation, not specialized computation. A similar conclusion could be drawn when a comparison is made between the system design of Ethereum (universal), and Nexus (specialized).

© Copyright 2019 Content by www.nexus.io

Nexus Contracts

Nexus has developed a Register-based Contract Engine (RVM), with greater capabilities than other contracting engines. Unlike the EVM for example, which is defined by only two distinct layers of processing and is dependent on a Turing complete system, the Nexus contract engine is facilitated through the seven individual layers of the Nexus Software Stack, each designated to carry out a specialized process.

The third layer of processing is called the Register Layer. Here, the states of individual pieces of information contained by Nexus Contracts are recorded in architectural components called registers. Registers are used by typical computer processors and provide easy access to memory storage of frequently used information or values. With respect to Nexus Contracts, each register is owned by a Signature Chain. Therefore, the ownership and write access of a register is validated by the second layer, the Ledger Layer. The fourth layer is the Operation Layer, which defines the rules of the state changes to a register, called ‘operations’. The operations are carried out by validating nodes that change the state of the registers by consensus. The design provides the required functionality of a contract engine, without the over complexity and complications of a Turing complete system.

The ownership of a register can be transferred providing many proof of ownership use cases. Examples of such include titles, deeds, digital certificates and records, agreements, or any other digital means of representing tangible assets or time-stamped events. A register can also be owned and governed by another register, creating a relationship between many users. Relations can be used as proofs on the Operation Layer to provide additional functionality. An example of this would be a register that holds metadata representing the ownership of an item, and it being owned by another ‘token register’. The token ownership signifies partial ownership of the item, which provides the possibility for further use cases such as royalty payments with split ownership.

Conditions or stipulations can also be coded into Nexus Contracts by validation scripts or Boolean logic. Validation scripts require a transaction to fulfill a certain set of conditions to execute, which allows a user to program in stipulations on the exchange of NXS, tokens or any other digital asset. This allows a user to void transaction orders, place time locks on funds, or exchange any digital asset without a central intermediary.

Nexus Contracts are accessible through an API and can improve many existing processes, including digital ownership, tokenization of assets and enterprises, digital rights, royalty payments, supply chain management, escrow services, financial applications, legal documentation of digital signatures, and many more.

© Copyright 2019 Content by www.nexus.io

Conditional Contracts

Conditional Contracts are an agreement between participating parties, outlining a set of requirements that must be met for a transaction to complete. They are the building blocks that allow users to engage with one another, such as contract expiration, or the exchanging of items. More advanced forms of non-custodial escrow or arbitration are also possible. Conditional statements have no limit to their complexity, being capable of handling groups of groups of conditions that together evaluate to either true or false. In the case the conditions return true, this allows the recipient of the transaction to claim their funds or object (depending on if this was a TRANSFER or DEBIT). In the case that the recipient is unable to satisfy the conditions, after a period of time set by the sender, the transaction will be redeemable.

© Copyright 2019 Content by www.nexus.io