Since early March the tritium testnet has been functioning with the primitive core APIs and Operations, and we are now engaging with a security firm to perform a code audit. They will start an audit on the staging branch (tritium beta running over the legacy rules), and the wallet.
The Proof-of-Stake system is almost complete. The reward earned now goes to your spendable balance, whereas your stake remains locked up. If you make a transaction that withdraws from your stake account, it will result in a partial loss of trust, depending on the percent withdrawn.
Recovery of Signature Chains
We have designed a method for password recovery, by developing into the signature chain a ‘master seed’ or a ‘recovery’ phrase, which will be 20 words (128 bits of entropy), similar to hyper deterministic wallets for Bitcoin. The master seed phrase provides extra assurance, enabling one to recover their signature chain in the event of a forgotten password or compromised account.
With the implementation of signature chains, transactions come to your sig chain and then you are required to claim them. This is to prevent people from losing funds sent to non-existent accounts. All transactions will have a timeout after a certain duration which means a transaction can be returned to the sender if somebody doesn’t accept it within the set timeframe. This technology is facilitated through the use of validation scripts, that essentially are appended at the end of a transaction that specify its behavior or anything that is trying to claim it. One can debit or credit back to oneself as transactions are by nature reversible. The validation script will specify the time frame the transaction can return to the sender.
Object registers are now complete and running in the core, which allow user defined type-safe objects. They will combine together data members that are either mutable or immutable, and will be accessed or modified through different formats in the API such as JSON or XML.
Validation scripts operate on a 64-bit register virtual machine, whereas Ethereum operates as a 256-bit stack virtual machine. In this case, Ethereum has gone beyond the hardware’s limits which has lead to major slowdowns, being that the processor can only operate natively on 64 bits at a time. To add to this, an Ethereum account balance uses 256 bits, where a balance is unlikely ever to need more than 64 bits. This creates a massive bottleneck in the processing of every account on Ethereum, which is one reason they have found troubles scaling. Our register virtual machine performs at 30 to 50 nanoseconds per instruction, compared to an average instruction time on Ethereum being on the order of 1,767,258 nanoseconds. You can read in the article below about how moving gas computation to 64 bits, increased the Ethereum virtual machine performance by an order of 70%. This shows that using 64-bit CPUs to synthesize 256-bit arithmetic, produces significant performance losses for no apparent advantage.
API & SDK
SDKs (software development kits) are written in a native programming language, and are abstracted on top of the API, allowing one to make native calls to access the functionality of the actual API. Dino has been working on the Python SDK, and Daniesan on the C# SDK. We hope to see more community involvement in the development of SDKs. It is simplified to port into any language without having to handle the HTTP protocol. The API also will contain an ‘events’ processor that will automatically respond to notifications, to accept and claim new transactions.
Anyone who is keen to learn can join the testnet, can use a new cookbook Dino created that we hope will give better insight into the use of the API. The link is as follows:
The Module Framework & Wallet
The module framework is an exciting feature of the wallet. It has now been integrated into the main UI code. The core modules are complete and awaiting final security audits. We are in the process of obtaining developer certificates for both Apple and Microsoft for the auto updater, which means that the binaries themselves will be signed by a certificate that is approved through each of these vendors. This will also solve some of the flagging issues when downloading the application.
In the last Zoom meeting, Kendal gave a demonstration on the Binance module to show the functionality of a module:
Watch the Zoom 05/01/19 here
The following results are benchmark results running on a consumer grade Apple laptop:
[13:47:57.791] ADD::Processed 34.7858 million ops / second
[13:47:57.933] MUL::Processed 35.1867 million ops / second
[13:47:58.174] EXP::Processed 20.7175 million ops / second
[13:47:58.313] SUB::Processed 35.9769 million ops / second
[13:47:58.418] INC::Processed 38.1832 million ops / second
[13:47:58.523] DEC::Processed 38.1486 million ops / second
[13:47:58.663] DIV::Processed 35.8513 million ops / second
[13:47:58.805] MOD::Processed 35.1786 million ops / second
[13:47:59.211] SUBDATA::Processed 9.85513 million ops / second
[13:47:59.358] UNIFIED::Processed 20.3705 million ops / second
[13:48:00.353] Parse::5.02705 million values / second
[13:48:00.363] Write::102.072 million uint8_t / second
[13:48:00.374] Write::89.6941 million uint64_t / second
[13:48:00.384] Write::97.8953 million strings / second
[13:48:00.394] Write::98.5319 million vectors / second
[13:48:00.405] Read ::97.1723 million uint8_t / second
[13:48:00.405] Read ::97.1723 million uint8_t / second
[13:48:00.415] Read ::92.584 million uint64_t / second
[13:48:00.425] Read ::100.746 million strings / second
[13:48:00.436] Read ::93.633 million vectors / second
Signature Chain Generation with Argon2
In the first Zoom meeting of April, Colin showed the speed of signature chain generation. We have designed it to be slow, to limit offline password attacks. Generating a Genesis ID for a signature chain took 891 milliseconds. This means that if someone tried to brute force attack your account, Argon2 would limit the amount of passwords that can be guessed in a given period of time. Users will also be able to increase the duration of Argon2 to heighten security, and enterprise will be able to reduce it, to increase transaction speed.
Ethereum charges a fee per transaction called ‘gas’, which is based on the computational complexity of a contract. In the case of Nexus, we can choose what transactions will carry a fee. DEBITS and CREDITS will be free on Nexus, though other functions such as creating a token or registering a vanity name will have a cost to prevent them from being consumed. Our current fee model reduces the supply of NXS as demand increases.
In the first Zoom meeting of April, Colin presented a live demonstration of a split revenue payment, to exemplify the distribution of royalties between three parties.
Watch the Zoom 04/11/19 here
The below article introduces Fungible and Non-Fungible Tokens, and Hybrid and Sister networks, which will form the basis of the Nexus Ecosystem.
We have released a roadmap that outlines the core features of the TAO Framework, which will be updated to reflect ongoing development.
The following articles describe how reputation or trust embedded in a consensus mechanism have the ability to drastically improve its tolerance to malicious actors.
We attended 2 conferences in April:
- The BlockPass Security Token (STO) event which discussed the future of tokenized securities and blockchain applications.
- The Olympia London expo – a multi-feature event focusing on Blockchain, IoT, Cyber Security and AI/Big Data.
We also took part in our quarterly TechUK DLT Working Group – the paper we have been working on will be published in June.
Dino and Colin participated at the Prague IETF (Internet Engineering Task Force) at the end of March. They presented the 4th revision of the draft-farinacci-lisp-decent-03 where they showed screenshots of demos for the push-based and the new pull-based decentralized LISP mapping system. Once the main LISP RFCs are accepted as proposed standards, they will request working group adoption for LISP-Decent.
Thanks for reading,