Posted by on | Featured

Red October

Last October (2018) we launched our first public testnet. Its purpose was to:

  • Test various components in a more realistic environment.
  • Collect data on bots behavior.
  • Deliver something to you.

Taking into consideration our deadlines, and information from the test-net, we changed the architecture of the project to have something faster to develop but a bit less modular. We changed the initial code base https://gitlab.com/neurochaintech/bot/ and started on a new repository https://gitlab.com/neurochaintech/core/ (a lot of code has been reused). Almost a year later, we still stand by those changes.

What since ?

Installation

The main problems were:

  • Installation needs to be simpler.

– We have are working on an installer (cli.py)

  • Plate form portability issues. Some of you reported bots crashing with illegal instruction issue (#51 #120).

– Problem fixed (old dependency). We also tried to install the bot on a wider set of platforms. Please keep in mind that we will never be as good as you at finding the one that does not work.

Networking

A lot has been done here. Having a mesh network that works on in lab is a student project. Having one that can handle the Internet is a little bit tougher. The network is now more robust and tested.

Transactions

We passed from Bitcoin’s model to Ethereum’s one. Bitcoin chain transactions, where Ethereum use balances (like for your bank account). Change was motivated by performance issues. Our consensus gives the incentive to reuse the same address to keep increasing PII. By using the Bitcoin model, we ended up requesting almost all the blocks from block 0 to compute a balance, which takes time. The last changes also made transactions smaller, better TPS, smaller ledger, everyone happy!

Address

We used to have addresses and public keys. Addresses, like on Bitcoin, was a hash of the public key (+ data to verify address). You can have the address with the public key but not the opposite. Anyway, we only have public keys now (that are used as the address). This gives addresses that are a bit longer, but you don’t have to manage both. It Makes the project simpler. This was also motivated by the transaction format change.

Example of actual address: “An80z/xtJ+julvhEjzOvKdT4PKNXhOs8LmlCnSYFa3pZ”

Fork management

Forks happens, even on Bitcoin and Ethereum. Understand blocks forked because 2 or more miners found a valid block, not project forks lite Bitcoin cash… On Proof-of-Work (PoW) there is a financial incentive on not pursuing a forks (creating a block costs actual money). On PII, like on Proof-of-stake, forks are even more frequent and costless. We reached:

  • 3220 forks.
  • 117 in-directions on most forked paths.
 
 Http API

We now have an Http API allowing us to make transactions and monitor the bots. This API should not be open to the public when you install your bot, it should either be used for a wallet or monitoring your bot (especially during tests).

$ curl http://localhost:8080/balance?pubkey=A5mc7ff4DMn9DyLq2qcbAUMyHfmzlvKKbLWuXHlQmuCD
{"value":"30861119"}

The wallet is a web application that you can run locally like Myetherwallet. For now you need to connect that web application to your own bot. Since the connection between the web application is not meant to be secure (by design). At a later point we could provide a shared bot to answer wallet demands.

How it works?

1) You first generate a pair of keys from the web page (this can be done offline).
2) The application will ask you to download a file containing your private and public key.
This file is not encrypted, for now it is up to you to keep it safe. Next versions will have encryption.
3) You can then ask for your balance.
The bot need to have an up to date ledger.
For tests purposes your bot can be offline as long as it has enough information in its ledger.
4) You set your transaction information: outputs (amount and public key)
1. The web application will ask the bot to create a transaction (only your public key is needed for that operation)
2. The web application will then sign this transaction with your private key.
3. Once signed, the transaction and the signature are sent to the bot to be published (notice your private key never left you web app).

Consensus

It is now fully implemented in its final version.
Consensus gives you a score based on:

  • Transactions you made (Involvement).
  • How well to did your work as member of the assembly (Integrity).
    => Hot double mining.
    => Block validation.
  • The longer you keep your coins on an address the more enthalpy they gains, this allows even the less wealthy to enter some assemblies and it also make flooding transactions inefficient.
  • When you send coins your address lose a fraction of the enthalpy proportional to the amount you sent.
  • When sending and receiving transactions you gain entropy which is how we measure Involvment.

1) An assembly last 24 hours. PII for next assembly (n) is computed using transactions from the one before last (assembly n — 2). PII is computed by address (not bot).
2) The 500 highest score for the great electors of the new assembly.
3) A seed is generated using bits from every block on the n-2 assembly. This seed used to randomly choose blocks authors for the assembly.

A full article about consensus internals will be written later.

Project Numbers

Latest Test-Net

  • 48691 blocks
  • 610819 transactions
  • 3220 forks.
  • 117 indirections on most forked path.
  • 282MB ledger size

Code

Core

  • ~15k lines.
  • ~500KB size.
  • +1000 commits.
  • charts Yes, we also work Sundays.
  • CI

Web apps: Wallet, Blockexplorer and Faucet.

  • ~2k lines.
  • ~54 KB size.
  • +100 commits.

Now and Beyond?

Now:

  • A private test-net is beeing run. The one we should open to public in the next few weeks.
  • We are fixing minor issues, and improving security and stability.
  • Monitoring the network whily playing with is (adding bots, killing other, stopping everything and restart,… having fun).

Soon:

  • Testing performances: max TPS, minimum resources required, …
  • More security checks.
  • Openning the test-net:
  • Clean documentation.
  • Setting up a support infrastructure.
  • Security audits.
Comments are closed.