Wow, great work. Can't wait until it's released.
A few things I was pleasantly surprised to hear:
- The new blockchain processing architecture changes (and corresponding performance improvements) sound really amazing.
- The new permission/authorization system is also really great.
- Transferable account names!
- Finally the recognition that maintenance collateral is all that matters to support the peg. I assume this means shorts will be able to adjust collateral levels up and down as long as it satisfies the maintenance collateral limit, and actual partial covering is possible. Also, I would like to hear more about what a forced margin call is like in the new BitAsset system.
- Actual limit orders! No WYAIWYG.
- Bringing back TaPOS for added security (though it is optional).
I'm a little sad to hear that even the minimal existing barriers (in the form of TITAN) to prevent people from getting your transaction history and balance amounts will be removed (even though to someone sufficiently motivated they weren't actually protecting anyone's privacy), but I guess I expected that and it does provide a lot of other benefits. I just wish we can have some other tools later to help manage our privacy better.
One thing I am a little concerned with is if the fact that unique IDs are used rather than hashes means there are more vulnerabilities for successful attacks from a fake blockchain attack. If someone is able to fork everyone over to a new blockchain history with changes in that last 10 blocks or so could they possibly somehow cause someone elses transaction that was meant to send someone else funds send the attacker the funds instead if the attacker is able to "take over" the ID number the transaction was referring to? I guess I would need to actually understand how this new BitShares 2.0 blockchain engine works before I can better articulate this concern. Perhaps TaPOS where the transaction refers to a recent block on the correct chain could help prevent any potential attacks like that (if such attacks even exist)?
Another thing I was thinking about while reading about the changes was how the state is committed to disk only on exit. I understand that it stores the blocks to disk as it receives them so that it can always recover the database state from scratch if necessary. But I don't see why it couldn't periodically commit the database state to disk so that if it fails it doesn't need to replay from the last time the program successfully exited (which may be a long time ago). In fact, if memory usage is so low, I think it would be cool to use just double the memory by using some memory page copy-on-write system to take a snapshot of the memory state while continuing to evolve the other copy, and then asynchronously serializing the snapshot copy to disk. Then when that serialization is done, the memory of the snapshot copy can be freed from RAM to repeat the process over again by taking a snapshot of the evolved copy. In fact, maybe the serialization can be delayed by some period to ensure that the time limit for chain reorganization has passed and so that you know you (almost never) would need replay the blockchain from any committed state older the most recent one, which is probably less than 5 hours old.
Then there are the few things I would have really liked to see if we were going to have such a huge change that requires a complicated migration strategy, even though I of course didn't actually expect to see them. The biggest would be a way of repeatedly and asynchronously committing a snapshot of the state (one that could be agreed upon via the consensus protocol) to a single cryptographic hash that could be committed and approved by all the witnesses as part of their responsibilities. This could allow users to quickly bootstrap to the current state of the database using a copy of a recent serialized snapshot state (which would be less than a day old) and a trusted hash of a recent block. I know that the new engine should speed up replay dramatically, but this would also allow the node to not need to download the entire blockchain either (and they may be constrained by bandwidth more so than CPU speed) as long as they didn't care about transaction history. And in the long term, one of the old snapshot states (that everyone for sure agreed was valid) could effectively act as the new genesis state and allow for blockchain pruning to save disk space. Furthermore, if the commitment of the state snapshot to a single hash was done intelligently, it could allow anyone to provide small proofs of the existence of objects in the database state at the time of the snapshot, where the verifier only needs to trust that the majority of witnesses at the time they committed the hash of the state snapshot to the blockchain did not collude to provide a false proof. This could allow lightweight clients and hosted wallets to (independent of further participation by witnesses) provide the user extra assurance that their view of the database is correct (even if that extra assurance is delayed by a few hours).
Finally, I hope you guys haven't given up on the following:
- Hosting the web-based GUI interface locally. I of course would expect to be able to run a full node and have the web-based code running in my browser to connect the local daemon running on my local machine. But I would also like to be able to run a lightweight setup where the browser-based GUI securely connects to a trusted public server instead even if I am serving the browser code locally rather than from some other server. I don't want the only official lightweight GUI setup for using BitShares to require us to hope that a MITM attack (likely made possible with compromised certificate authorities) hasn't replaced the browser code with a version that phones home private keys. For regular users, I hope this also means that you are still working on a Chrome web app packaging the browser-based GUI to reduce the chances of a MITM attack.
- Will you still be working on the mobile QML wallet? Will the new web-based GUI be responsive and adaptive enough to be used on mobile? Even if so, I can't imagine that it could be as capable as an app specifically designed for the mobile platforms (Android and iOS). Will you not focus on this and instead allow third parties (e.g. ElMato's LimeWallet) to build the mobile-optimized BitShares clients?