Testnet 1.5 is  going to be launched today. The most important feature in this release is addition of custom assets.

An asset is basically id -> amount pair, where id is unique long (256-bits identifier).

A transaction can create a new assets if its id is equals to the id of the first input coin. Any output can contain then any amount of this new assets.

For assets, preservation law holds: sum of output amounts for each asset not created by the transaction should be no more than  sum of input amounts.

Each transaction output may contain up to 4 assets, transaction may operate with up to 16 assets.  

In the testnet 1.5 a miner by default creating a new asset each block, with issuance of 1000 tokens.

Currently many things are done in very inefficient way, bootstrapping, networking protocol are far from optimal. We have fixed few things in 1.5.0. And we have added support for improving more in further 1.5.x. releases, such as services announce during handshaking (like Bitcoin is doing) for efficient  bootstrapping in multi-mode environment.

This week we published a draft of a new paper titled "Self-Reproducing Coins as Universal Turing Machine" https://arxiv.org/abs/1806.10116 .  This paper basically shows that Ergo is able to do Turing-complete computations (probably, it is more precise to say that is is able to hold a log of Turing-complete computations). The proof is done by showing how to run one of a simplest Turing-complete systems, Wolfram's Rule110 (https://en.wikipedia.org/wiki/Rule_110), over the Ergo blockchain.

However, Rule110 is utterly primitive system, one can not do much with it. On other hand, much more complex systems are doable with Ergo. The open question is what is not doable in Ergo under concrete restrictions (such as number of registers in a transaction output, and a limit on a script computational complexity; the latter will be adjustable by miners like gas limit per block in Ethereum though).

Let me philosophize a little bit on what Ergo is.  Bitcoin is a digital gold system, with some primitive spending conditions to be set on coins. Ethereum is a fully replicated programmable calculator, which is storing a lot of communicating processing sleeping before being awaken by an incoming transaction (with a lot of trivial and non-trivial side-effects, sometimes counter-intuitive or simply dangerous).

Ergo is a storage of rich state. You can create a coin (an output) which is requiring a spending transaction to create an output with the same script, or with an amount somehow related to the amount of the coin to be spent. You can have arbitrary data stored in your coin (in form of typed registers).  With the state and rules being set in a particular way, you can simulate a Turing machine, or do a crowdfunding or oracles  in a simple way (we have examples in the repository which holds our transactional language (https://github.com/ScorexFoundation/sigmastate-interpreter).

Despite the richer functionality, our language is safer that Bitcoin's (computational complexity could be decided before an actual execution, and a block which is too heavy to validate could be rejected early and without much burden).

Recently an example of a finite state machine have been shown (https://github.com/ScorexFoundation/sigmastate-interpreter/blob/34afeb4db149d516adfe98cd24e469699eb56456/src/test/scala/sigmastate/utxo/examples/FsmExampleSpecification.scala). FSMs are important as there were some proposals to use them to describe financial contracts (e.g. https://www.financialresearch.gov/working-papers/files/OFRwp-2015-04_Contract-as-Automaton-The-Computational-Representation-of-Financial-Agreements.pdf ). FSMs in Ergo are like MAST in Bitcoin, but more powerful (cycles in execution are possible). For each step of a contract execution, only current state identifier, and a commitment to FSM description are stored, to perform a step, an user must show correct script and also an outcome state identifier (corresponding to a FSM description, which is basically about tree root hash).


We are working on custom tokens, hopefully a testnet with tokens support will be launched next week. After the testnet launch (version 1.5.0 of the reference implementation), we will release 1.5.1 shortly with optimizations in bootstrapping and memory footprint. In July we'll work on  networking layer optimizations and efficiency of the client. Also, PoW research will be started
 

How to convert Ergo tokens on waves platform to native tokens of Ergo?

Reference client 1.0.1 with bugfixes and optimizations has been released! https://github.com/ergoplatform/ergo/releases/tag/v1.0.1

1.0.2 is on the way.


The plan to release a new testnet 1.5 with custom tokens is still on the table.

Sorry for the delay, Friday has been sent in a train.

The team spent last days on maintaining and cleaning things after Testnet1 launch. That time I've given a couple of talks @ BCC workshop in Korea (associated w. AsiaCCS, more info are available from this tweet https://twitter.com/ergoplatformorg/status/1003260343659978753 ).

The next steps are finalization of Proof-of-Work, voting systems and soft-forkability, tokens and economy.

In order to have smooth launches of next testnets, we consider to release them more often. In particular, next testnet, Testnet1.5, is planned to launched on July, 1st. It will contain custom tokens support
(and some updates in the smart contracts language).

  

Would that mean that the mining algo will be changed? Because ASIC have been developped for Equihash. This is a strong debate in the ZCash community.

Mainnet is pretty far, but what is the team stance on ASIC? I'm looking at the Antminer Z9 mini in particular.

25.05.2018: pretty minor update, as we're simply working. In particular, we're finishing merging our new transactional  \Sigma-state language. Initial code will be around Monday. There's significant progress with specification as well: you can details on details of coins and transactions constructions. Signature section is mostly ready and will be finished within next few days. Current spec draft: https://github.com/ergoplatform/ergo/blob/def485c3ce9a0565d51dced3d6ddff27765bfcc1/papers/yellow/main.pdf . Currently, the estimated day to launch Testnet1 is still June, 1st.

18.05 update:

We're on track, so testnet2 release is planned on June,1st. We're finishing serialization of spending proofs, coins and transactions, and also a specification which will be online within next few days.

Testnet 1 transactional model features:
- Schnorr protocol and proof of Diffie-Hellman tuple knowledge protocol as building blocks (proof of Pedersen Commitment knowledge will be added later)
- Arbitrarily complex AND and OR conjectures (to build complex multisig schemes). Threshold conjectures will be added later.
- SecP384R1 curve
- A lot of (typed) predicates over blockchain state. We have many examples (see my prev. message) to test the network!
- No implicit rules to produce money out of thin air. No coinbase transactions, no implicit fee (we assume that a fee should be a spendable-by-anyone coin which will be claimed by a miner in a last transaction in a block). All the coins rewarding miners (presumably)  will be created before the genesis block (in a genesis UTXO set) and locked up to certain heights. Details in the spec.
 

From now on, I will provide weekly updates, mostly on Fridays.

We're now working very hard towards next testing network, Testnet1. Release is planned around June, 1st. The main feature for this release is our brand new transactional language Sigma-State. We already have many examples in this language: P2SH, MAST, crowdfunding, demurrage currency, oracles etc. Complexity of language expressions can be decided before an execution, complex signature schemes are coming out-of-box! We're working on the language whitepaper, I'm also writing down transaction format specification.

After testnet1 release, we will work on design finalization, namely ASIC resistance, fighting with work outsourcing (pools), finalizing contract details, possible proof-of-storage scheme, system parameters upgrade via miners voting etc. Testnet2 should be similar to mainnet.

On research side, some exciting solution for fully stateless clients is coming!