1. Core status?
Core now also consists of asset-to-asset exchange, this was added recently on top of payments which were already functional.
Testing is done with a technique i call mirrorring, its very similar to how payments used to be tested. The tests for payments were not sufficient for testing orders, unconfirmed order matching and also supporting rollbacks and testing blockchain reorgs.
For this the test code really had to support some way that mimics the way the storage backend supports rollbacks to previous versions AND support transactional operations where either all or none of the changes during a storage transaction were commited to the data storage.
The mirroring mode can be switched on through the app configuration and has separate logic that keeps a one to one clone of the blockchain but in memory, all balances of accounts and assets and orders plus unconfirmed balances are kept track of. But with separate code that does all the calculations itself and does not rely on the code that does this for the main heat balances.
This way when you start heat mirrored and you do a transaction, the same changes to the sender and recipient account balance and unconfirmed balance that happen in the heat storage also are applied to the in memory balances. This supports rollbacks and any possible restores in case an error occurs and a transactional storage operation must be unwound. If you add to the mix that after each operation you compare the heat balance storage with the in memory clone of the balances - you can basically confirm that at least the heat balance updating logic and the code that does the same thing in the mirroring parts are actually in sync.
What remains now are two things. A. Find a way to throw as much and as different as possible transactions at heat while running in mirrored mode (the more difficult the better since you'd ensure all possible code paths are handled). B. Make sure to manually go over the code that does the mirroring analyse it as best as possible and make sure its sound. That last part is actually much easier as compared to manually going over the code that does the same balance handling for in the heat parts. That's because the mirrored code is just a fraction of the size of the code for heat balance tracking - only the most essential parts are there.
When changes are made to heat core code - new transactions added - new asset classes introduced - pop rewards get enabled etc.. We now have a built in diagnostics mechanism, not very much unlike ethereum uses several clients written in several languages that also perform their self-diagnostics.
To assist in sending as much and as different as possible transactions to heat we added the concept of apps which are javascript/nodejs/npm modules you can reference on the command line and have heat load those in the java js vm. Helper classes are injected into those scripts that allow you to easily send transactions, generate blocks, etc. Works really easy. Its not the same as microservices which are also scripts but meant to run and respond to events on the live network. Apps are run instead of the main blockchain, you can assign their own blockchain and configurations through their package.json file. Purpose of apps are either running tests or doing analisys of the blockchain, app scripts run from start to finish and shutdown. Microsservices keep running in the background for ever.
2. Asset exchange status?
The replication parts (detailed optional database model - kept in real-time sync) have been completed and operational. This involves all trade history and all order history which is not needed for consensus and thus has no part in heat core. These replicated parts are now also accessible from the api, use them to list trades and orders and search for them etc.
3. Email account identifiers
To support human readable account identifiers instead of forcing users to remember and exchange numerical account ids we have completed the account identifier parts. What we wanted is a mechanism where users can safely use their own private email addresses as their account identifiers - yet not have a trace of that actual email address on the blockchain. This comes down to user a registering id "
[email protected]", yet not leaving a trace on the blockchain. Yet when some other user sends a payment to "
[email protected]" the payment will go to the correct account. If you wish so you can register your account identifier to be public on the blockchain. It is also possible for another account to assign an identifier for your account - but only after you provide a signed messages, signed with your private key which the assigning account has to provide.
The storage of account ids happens not as actual textual identifiers but as 8 byte longs, very similar to how we generate numeric account ids from the much larger public keys. The range of unsigned 8 byte longs is 18,000,000,000,000,000,000 or 18 billion billion. Which we think is more than enough to support most users unique names yet have have very little to no false positives.
To be able to support account auto completion in the client the replication layer has functionality to store all non-private identifiers and make them searchable. Assigning or announcing names for accounts happens transparantly very similar to announcing public keys and can be done at no extra cost when sending a transaction.