I read the information above and it looks a potential project, I hope to invest it a little bit. A lot of potential is here for these project!
I think it is too early to make any hasty conclusions about the project. But of course, ahead of the project may get more popularity and will be in demand in the market. 
Topic: [PRE-ANN] Ergo Platform is coming, the AAA class of blockchains - page 9. (Read 33840 times)
August 15, 2018, 11:47:49 AM
August 15, 2018, 11:38:53 AM
1.53 is ready and will be released this week. It contains significant improvements in bootstrapping and networking layer efficiency.
Initial wallet prototype is ready, code is under review.
Maybe we will rollout new testnets, say, bi-weekly, as it is hard to manage a huge codebase update properly. So, instead of a single enormous Testnet2 release, we'll roll-out few updates (fee model, system reconfiguration, PoW finalization).
On EFYT <-> ERGO exchange:
1. Before the mainnet launch, we'll send EFYTD (EFYT alternative for data chain).
2. Waves <-> Ergo gateway will exist. Thus Ergo token will exist on top of Waves as well.
3. With money got via founders rewards, the Foundation will create orders on Waves exchange, to buy EFYT for ERGO, the price is 1.00
Initial wallet prototype is ready, code is under review.
Maybe we will rollout new testnets, say, bi-weekly, as it is hard to manage a huge codebase update properly. So, instead of a single enormous Testnet2 release, we'll roll-out few updates (fee model, system reconfiguration, PoW finalization).
On EFYT <-> ERGO exchange:
1. Before the mainnet launch, we'll send EFYTD (EFYT alternative for data chain).
2. Waves <-> Ergo gateway will exist. Thus Ergo token will exist on top of Waves as well.
3. With money got via founders rewards, the Foundation will create orders on Waves exchange, to buy EFYT for ERGO, the price is 1.00
https://twitter.com/ergoplatformorg/status/1029766801612255232
August 15, 2018, 10:52:22 AM
1.53 is ready and will be released this week. It contains significant improvements in bootstrapping and networking layer efficiency.
Initial wallet prototype is ready, code is under review.
Maybe we will rollout new testnets, say, bi-weekly, as it is hard to manage a huge codebase update properly. So, instead of a single enormous Testnet2 release, we'll roll-out few updates (fee model, system reconfiguration, PoW finalization).
On EFYT <-> ERGO exchange:
1. Before the mainnet launch, we'll send EFYTD (EFYT alternative for data chain).
2. Waves <-> Ergo gateway will exist. Thus Ergo token will exist on top of Waves as well.
3. With money got via founders rewards, the Foundation will create orders on Waves exchange, to buy EFYT for ERGO, the price is 1.00
Initial wallet prototype is ready, code is under review.
Maybe we will rollout new testnets, say, bi-weekly, as it is hard to manage a huge codebase update properly. So, instead of a single enormous Testnet2 release, we'll roll-out few updates (fee model, system reconfiguration, PoW finalization).
On EFYT <-> ERGO exchange:
1. Before the mainnet launch, we'll send EFYTD (EFYT alternative for data chain).
2. Waves <-> Ergo gateway will exist. Thus Ergo token will exist on top of Waves as well.
3. With money got via founders rewards, the Foundation will create orders on Waves exchange, to buy EFYT for ERGO, the price is 1.00
August 13, 2018, 10:45:53 AM
I read the information above and it looks a potential project, I hope to invest it a little bit. A lot of potential is here for these project!
August 04, 2018, 02:46:22 AM
Summer is hot!
- Transaction and block validation rules has been added to the specification (Yellow Paper)
- We consider names for our transactional languages. Low-level language will be called ErgoTree (as it is a typed abstract syntax tree, to be written into the blockchain in a serialized form).
Higher-level language is called ErgoScript, an example in this language:Quoteguard CrowdFunding(timeout: Int, minToRaise: Int,
backerPubKey: Sigma, projectPubKey: Sigma) {
let c1 = HEIGHT >= timeout && backerPubKey
let c2 = allOf(Array(
HEIGHT < timeout,
projectPubKey,
OUTPUTS.exists(fun (out: Box) = {
out.value >= minToRaise && out.propositionBytes == projectPubKey.propBytes
})
))
c1 || c2
} - EFYT <-> Ergo transfer details will be announced next Fri hopefully.
- We have a lot of material to be included into the next minor release (1.53): various improvements to the network layer and synchronization (https://github.com/ScorexFoundation/Scorex/pull/280 and https://github.com/ergoplatform/ergo/pull/386), and first stage of the wallet implementation (https://github.com/ergoplatform/ergo/pull/362). Both sets of features are now under review & testing. Probably 1.53 will be out next week with one set of new features or another, or both.
https://twitter.com/ergoplatformorg/status/1025489957710974976
August 03, 2018, 03:49:26 PM
Summer is hot!
- Transaction and block validation rules has been added to the specification (Yellow Paper)
- We consider names for our transactional languages. Low-level language will be called ErgoTree (as it is a typed abstract syntax tree, to be written into the blockchain in a serialized form).
Higher-level language is called ErgoScript, an example in this language:Quoteguard CrowdFunding(timeout: Int, minToRaise: Int,
backerPubKey: Sigma, projectPubKey: Sigma) {
let c1 = HEIGHT >= timeout && backerPubKey
let c2 = allOf(Array(
HEIGHT < timeout,
projectPubKey,
OUTPUTS.exists(fun (out: Box) = {
out.value >= minToRaise && out.propositionBytes == projectPubKey.propBytes
})
))
c1 || c2
} - EFYT <-> Ergo transfer details will be announced next Fri hopefully.
- We have a lot of material to be included into the next minor release (1.53): various improvements to the network layer and synchronization (https://github.com/ScorexFoundation/Scorex/pull/280 and https://github.com/ergoplatform/ergo/pull/386), and first stage of the wallet implementation (https://github.com/ergoplatform/ergo/pull/362). Both sets of features are now under review & testing. Probably 1.53 will be out next week with one set of new features or another, or both.
This update is short 
With initial load tests, we found some a couple of performance degradation bugs in 1.5.1. Blockchain processing (for a full node) in 1.5.2 is 30x faster than in 1.5.1 so please use 1.5.2. Next week we'll release a new minor version with initial prototype wallet API.
With initial load tests, we found some a couple of performance degradation bugs in 1.5.1. Blockchain processing (for a full node) in 1.5.2 is 30x faster than in 1.5.1 so please use 1.5.2. Next week we'll release a new minor version with initial prototype wallet API.
"Since we mainly write code rather than promote our project, a lot of people ask me what Ergo Platform is. I prepared a presentation to answer these people hoping that it will be useful even without my comments"
https://twitter.com/DmitryMeshkov/status/1019311829372276736
https://twitter.com/DmitryMeshkov/status/1019311829372276736
We're in the middle of writing wallet and thanks to a transaction generator fixed (after being broken in Testnet1 release), initial tests with big transactions included into blocks done. We found some bugs.
In particular, add this line for now:
maxPacketSize = 2048576
under
scorex {
network {
We already have a fix a corresponding issue. On Monday we'll release 1.5.1 bugfix release (with some other fixes as well).
Around Jul, 20-24, we'll release 1.5.2 release with initial wallet prototype functionality (only API calls and API interface, no other UI).
On research side, we're starting PoW research. And our paper "Self-Reproducing Coins as Universal Turing Machine" (https://arxiv.org/abs/1806.10116) has been accepted to CBT workshop associated with ESORICS'18 http://deic.uab.cat/conferences/cbt/cbt2018/.
In particular, add this line for now:
maxPacketSize = 2048576
under
scorex {
network {
We already have a fix a corresponding issue. On Monday we'll release 1.5.1 bugfix release (with some other fixes as well).
Around Jul, 20-24, we'll release 1.5.2 release with initial wallet prototype functionality (only API calls and API interface, no other UI).
On research side, we're starting PoW research. And our paper "Self-Reproducing Coins as Universal Turing Machine" (https://arxiv.org/abs/1806.10116) has been accepted to CBT workshop associated with ESORICS'18 http://deic.uab.cat/conferences/cbt/cbt2018/.
1.5.1 has been released https://github.com/ergoplatform/ergo/releases/tag/v1.5.1
https://twitter.com/ergoplatformorg/status/1018420805661839360
https://twitter.com/ergoplatformorg/status/1018919356682694656
Nice team and nice project. I'm very hopefully about this. Good luck for your team.
1.5.1 has been released https://github.com/ergoplatform/ergo/releases/tag/v1.5.1
Looking forward for future details
We're in the middle of writing wallet and thanks to a transaction generator fixed (after being broken in Testnet1 release), initial tests with big transactions included into blocks done. We found some bugs.
In particular, add this line for now:
maxPacketSize = 2048576
under
scorex {
network {
We already have a fix a corresponding issue. On Monday we'll release 1.5.1 bugfix release (with some other fixes as well).
Around Jul, 20-24, we'll release 1.5.2 release with initial wallet prototype functionality (only API calls and API interface, no other UI).
On research side, we're starting PoW research. And our paper "Self-Reproducing Coins as Universal Turing Machine" (https://arxiv.org/abs/1806.10116) has been accepted to CBT workshop associated with ESORICS'18 http://deic.uab.cat/conferences/cbt/cbt2018/.
In particular, add this line for now:
maxPacketSize = 2048576
under
scorex {
network {
We already have a fix a corresponding issue. On Monday we'll release 1.5.1 bugfix release (with some other fixes as well).
Around Jul, 20-24, we'll release 1.5.2 release with initial wallet prototype functionality (only API calls and API interface, no other UI).
On research side, we're starting PoW research. And our paper "Self-Reproducing Coins as Universal Turing Machine" (https://arxiv.org/abs/1806.10116) has been accepted to CBT workshop associated with ESORICS'18 http://deic.uab.cat/conferences/cbt/cbt2018/.
Our latest paper on Turing-completeness got accepted to International Workshop on Cryptocurrencies and Blockchain Technology - CBT'18
https://twitter.com/ergoplatformorg/status/1016978844681752576
The official Ergo Platform Testnet explorer is here! https://testnet.ergoplatform.com Please report any bugs in our Telegram channel https://t.me/ergoplatform
https://twitter.com/ergoplatformorg/status/1017059445862555648
https://twitter.com/ergoplatformorg/status/1016978844681752576
The official Ergo Platform Testnet explorer is here! https://testnet.ergoplatform.com Please report any bugs in our Telegram channel https://t.me/ergoplatform
https://twitter.com/ergoplatformorg/status/1017059445862555648
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.
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.
https://twitter.com/ergoplatformorg/status/1015180725182697473
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.
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
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
Jump to: