This is an excerpt from a much larger impromptu Q&A on Nexus Telegram, and provides an excellent overview of Nexus architecture. (edited for clarity)

---------------------------------------------------------------------

Paul Screen, [10.09.19 22:03]

[In reply to CryptoJoker]

yes it is. There's no question that ethereum and it's direct competitors that offer turing-complete programmable contracts are very powerful. But when you actually look at the requirements of businesses trying to onboard to blockchain, we found that most of them just need simple requirements met and don't need all of the complexity and baggage that comes with it.

​

CryptoJoker, [10.09.19 22:04]

[In reply to Paul Screen]

ok so ca u run only simple multi conditional transactions on the nexus VM or facebook type DAPPs on nexus ?

​

Viz., [10.09.19 22:09]

[In reply to CryptoJoker]

Nah the VM is the interpreter so the language fits on top, we haven’t designed nexus to be a programming language this is an approach we didn’t agree with. It is APi based so you can code in any language and work with the functionality of the blockchain layer for what you need it to do. No you can’t port EVM code into Nexus

​

CryptoJoker, [11.09.19 00:22]

[In reply to Viz.]

when you make an api request, does this result in computations done on the blockchain ?

​

Viz., [11.09.19 00:23]

It depends on the API request, if you do let’s say users/list/notifications then no as this is reading data, but finance/credit/account would since it broadcasts a transaction with OP::CREDIT

​

CryptoJoker, [11.09.19 00:24]

[In reply to Viz.]

ok thanks , and can you provide me an idea of the flexbility of the VM on nexus ? can it run like facebook type dapps for example ?

​

Viz., [11.09.19 00:28]

It depends, it depends on what you want the blockchain to do and don’t. Dapp is an overused word and overstated in capability because a blockchain isn’t a computer and shouldn’t ever be, it’s a verifier. So, if you wanted to make a social network on nexus, trade tokens, chat, sure you could. A lot of functionality will be in the logical Layer as there’s no point to compute let’s say an image compression on the blockchain, you would on the logical Layer compress it, hash it, then build an object Register to hold the meta data associated with it that includes the checksum, include description. Then to update, you change the state in the object register, etc. If you wanted to do conditions in some of these interactions you could program the Boolean expression in such as, I’ll sell you this object for 5 NXS, someone is able to claim the transfer based on the condition of their debit, so on.

​

CryptoJoker, [11.09.19 00:29]

[In reply to CryptoJoker]

how does the functinonality of the nexus scripts compare to that of bitcoin scripts ?

is it fair to assume this:

bitcoin scripting < nexus scripting < ethereum type smart contracts ?

it seems like its mostly built to handle only transactions ...

​

Viz., [11.09.19 00:31]

[In reply to CryptoJoker]

Not really, our architecture is completely different, hard to compare functionality. Let’s just say bitcoin scripts are slow, clunky, and stack based and only handle a Boolean expression to spend inputs, ours is a register based system with primitive operations and conditions that all interact to provide contract functionality

​

Viz., [11.09.19 00:31]

[In reply to CryptoJoker]

You miss what the term register means then

And “programmable data structures”

​

CryptoJoker, [11.09.19 00:31]

[In reply to Viz.]

yes, this is the first time i am encountering this

i also dont have a programming background unfortunately

​

Viz., [11.09.19 00:33]

A register is a structure that on hardware is what your cpu uses to store numbers in low latency memory (close to the CPU in its internal cache).... hang on, switching to computer...

​

CryptoJoker, [11.09.19 00:34]

[In reply to Viz.]

ok this is all fine and good, but i guess for a layman like me i just wanna know what its functionalities are in comparison to EVM type VMs ...

what can it do in comparison to EVMs, and is it faster/slower, more expensive/cheaper ?

​

Viz., [11.09.19 00:36]

Let me explain it like this: Ethereum is like everything put in one bucket, it has a turing complete byte code because they imagined you could program it like a universal computer. The reality is though, that most people abstract away from the EVM and use it for pure data storage, or managing accounts and tokens. They include operations like EXP for example, and use what is termed "Big Numbers" which are numbers that are in the range of 2^256 which is a number with over a hundred zeros. This has led to significant bottlenecks, and little value in being turing complete even though this was their value propositiion.

​

Viz., [11.09.19 00:36]

Now we get to Bitcoin, which was deliberatly not turing complete, and its scripts were designed to control the conditions on spending inputs in the UTXO model, in which it has proven useful, and some scripts such as OP_RETURN have allowed people to store data on it, but then again it aws not useful for much more than that.

​

Viz., [11.09.19 00:37]

Then we get to us, think of us between bitcoin and ethereum, but building contracts to act like contracts between people, rather than computer code.

​

Viz., [11.09.19 00:41]

So think of us as a blend of the two concepts, but in a way that is practical and useful for developers. From my research of talking to many companies that were using blockchain, I deduced a simple common denominator: nobody used ethereum for the turing completeness, they used it to store data. This was the foundation of the architecture that I developed for tritium that is a seven layer stack. So I'm going to break this down, and hope this communicates how it functions to create smart contracts or dapps in just about any capacity that's needed:

​

Viz., [11.09.19 00:41]

1. Network - this is responsible for end to end communication between nodes, handling the relaying and receiving of ledger level data

​

Viz., [11.09.19 00:43]

1. Ledger - this is responsible for ensuring all data is formed under consensus and is immutable by nature. This is where your 'sigchain' or blockchain account exists. A sigchain is a decentralized blockchain account that allows you to login from any node with a username, password, and pin without the need for wallet.dat files or constantly rescanning the database. This is an important piece to how the layers above work as well, think of it as a personal blockchain that allows decentralized access through the login system that does not store any credentials, but rather deterministically creates a 'lock' mathematically that only your credentials can unlock, using a few different cryptographic functions I won't name here

​

Viz., [11.09.19 00:46]

1. Register - this layer is the data retention layer, or the layer that stores information relating to users. A register takes two forms: state and object. A state register is jsut a simple register that can store data in any sequence with no formatting enforced by the ledger. This would be for applications that have a state they want to remain immutable whih they can record in a state register. The second form is an object register, which is a programmable data type. What this means is that I can specify the fields of this register, and set some of the fields to be mutable or immutable such as lets say S/N would be immutable, but notes mutable. This allows objects to take the form much like a struct or class in object oritented languages, that can be accessed by any node, and only written to by the owning sigchain. Now registers sit on top of the ledger, and they can be transferred between sigchains or users, allowing them to take a natural form as assets or simple objects that would be included in a decentralized application such as a crypto kitty, or a post yoj make on social media, etc. This layer is responsible for managing all these states and ensuring the specified fields in these states are immutable, while other fi9elds can be updated like a program would do as it operates.

​

Viz., [11.09.19 00:51]

1. Operation - this layer is what gives context to a register and causes some action to take place. It includes two aspects to this layer, Primitive operations and Conditional operations. A contract object is a self contained object containing: a register pre-state (the register that is being operated on), a primitive operation (only one primitive operation per contract), and a set of conditions (any amount of conditional ops may be used for a fee of course). The primitive operations are basic ones like WRITE, APPEND, DEBIT, CREDIT, TRANSFER, CLAIM, CREATE, AUTHORIZE, TRUST, CONBASE, GENERATE. Each of these has a specific operation on the register it is initiated in. This is how you would maintain the state of a decentralized app, lets say crypto kitties, you have an object register that you create with OP::CREATE that has a specific meta data format associated with it, you then OP::TRANSFER it to someone else, but you gie a condition saying they must send 500 NXS beforehand, and this is the stiuplation of the TRANSFER being CLAIMABLE. When this ondition is satisfied you are able to claim the other point allowing for forms of exhange. Other stipulations or conditions could be arbitration, escrow, etc. Conditions are when there is an interaction between two actors or sigchains, which happens with a DEBIT or TRANSFER. Otherwise the other primitive oeprations act on the register such as changing its state.

​

Viz., [11.09.19 00:52]

1. API - This layer is responsible for giving an interface for the programmer to build their DAPP. This gies them direct access to login, create registers, create accounts, send coins, read data, manage notifications, etc. This is the layer develoeprs will interact with when building applications.

​

Viz., [11.09.19 00:53]

1. Logical - This is the first 'developer' layer, menaing that this is the layer that will give most of the logic to the application. This coudl be simple things like, send message to this user if they have this object that has a value of 'you're my friend' ,or antything else. This layer is the 'backend' of the dapp, and what provides a lot of the functionality. States can be read and written into the register layer, information from the ledger can be shared, stipulations on interactions can be applied. etc.

​

Viz., [11.09.19 00:54]

1. Interface - This is the 'user' layer, where the user will interact with. This in the facebook example would be the website you go to, and all the buttons that do fun stuff. This is the last layer of the 'developer' application space.

​

CryptoJoker, [11.09.19 00:54]

thank you

big applause!!!!

​

CryptoJoker, [11.09.19 00:56]

ok so to summarize my understanding of this

3 allows for creation and transfer of digital assets/objects

4 governs the operations that on objects in 3

5 interface between dapp logic and register/operations layer

1. this is where the "dapp" is written by developers
   

am i right ?

​

Viz., [11.09.19 00:57]

So as you can see, all these layers together are what form the foundation of a dapp, with the blockchain doing some things, the application does other things. They togheter give the blockchain scability and easy to build on, and also give the appliation powerful tools to utilize. For example of an object register, your NXS account. It contains fields identifier and balance. The identifier identfies the token's contract-id or object register, and the balance keeps track of how much you have at stake. Object registers can be polymorphic though, so you can create an object register with tehse two base types, but add, notes, which you could fill with personal notes and the DEBIT and CREDIT operations would process it off of the base object, or the account menaing that you can expand from these basic objects and create many different types and uses, creating object oriented and polymorphic behavior

​

Viz., [11.09.19 00:57]

3 is simply where they are store, it takes 4 to create the object

5 yes

6 yes plus 7, the dapp space is layers 6 and 7 together. If the dapp developer is really good though, they make custom API's with more complex contracts under the hood to provide additional functionality to their dapp, but we currently abstract the developer away from this to prevent them making mistakes that could lose people a lot of money

​

CryptoJoker, [11.09.19 00:59]

whereas for the EVM, 3,4,5,6 and 7 are all bundles into one entitiy, am i right ?

​

Viz., [11.09.19 00:59]

And last note, on layer 4, the conditional statements. These also operate on a register based VM that processes the conditional statements, and they can be grouped with as many different conditions as desired, so they can grow into quite complex contracts like we would see with legal contracts.

​

Viz., [11.09.19 01:00]

EVM doesn't really have layers

It's just EVM opcodes, and then the compiler for solidity which creates the byte code, so maybe two layers

Same with bitcoin scripts

But bitcoin scripts dont have a compiler that creates the byte code so you have to program it as a type of assembly

​

Viz., [11.09.19 01:01]

So long story short is, our techniques and architecture are quite unique, and designed around years of market research to ensure that it was built as something that people could use easily, but also powerful enough to power the dapps people want to see

​

Viz., [11.09.19 01:03]

The login account is really important for adoption in my opinion, because users having to manage keys wont bode well for applications that expand, lets say like supply chains or other mobile applications. Managing keys in a file on your computer I think is a big hurdle to mainstream adoption, the other one is the complexity of EVM and how little practical appliation it has, even though it contains a lot of functionality, most of it us unused or abstracted away from