[[Development Update]]
Hi all,
For now, I'll be using this thread to share development status. If there is a lot of interest in the development discussion, I might create a new thread.
There are currently two developers working on this project - Thies1965 and myself. If anyone is interested in contributing, please PM me. We're always happy to get more help
, and we do have a few development shares to give out for people who help out.
NXT is the inspiration of this project, but the current plan is not to use the NXT code without making significant changes. For one, I would like to rewrite / refactor much of the NXT code to make the code compliant with development best practices (including unit tests). My background is in enterprise software, so I'm confident that we can improve off of NXT and make it better.
Right now, we have a simple git repo:
https://github.com/NxtEM/nem. It's empty at the moment aside from two versions of NXT: the "official" 0.4.7e released by Jean-Luc and the decompiled 0.5.10 version. Both are browsable and we don't have any plans on taking them down until NEM is near completion.
Depending on who wants to join the development team, I'll be keeping the language choice open until the weekend. The current preference is Java (like NXT), but I would be open to changing it depending on the interest.
The first chunk of work will be around building all the classes that comprise the blockchain.
- I'm planning to change the signing algorithm from NXT's non-standard curve25519 based implementation to ed25519 (
https://github.com/geir54/ed25519-java/blob/master/ed25519.java).
- I will also change the account numbers to be more bitcoin-like
Let me know what you think.
@Jaguar and Theis. Some thoughts from a friend.
-----------
There are things that I don’t like about NXT or that I think could be done differently.
1. Storing whole blockchain in memory.
imo, “app” should be split into 3 parts:
1. server, storing blockchain and all related info in DB - this one would be used for all the SERIOUS stuff (so exchages, faucets, and any other apps like that would run this)
2. lightweight IN-BROWSER client - I think CfB has similar idea - that one, would have ZERO knowledge itself it, but I think it’d be possible to do whole singing in-browser.
3. ‘normal’ client - for users, that want to participate in the network, but don’t want to deal with DB setup. This one would keep blockchain in memory, BUT it would rely on “snapshots”
a. snapshot would be created every X days (I was thinking about X=10)
b. they would contain information about state (of accounts), but would drop all the history
c. snapshots (for new clients) could be propagated in torrent-like fashion.
2. TPS rate. I’ve seen somewhere info, that Nxt could handle 100_000 TPS. I have some doubts about it. (current hardcoded limit for tx in block is 255, that would imply ~400 BLOCKS per sec).
I think software, should be thought upfront to handle large amount of transactions per second. (so for sure, somewhere “in future” there should be switch to binary protocol, also it might be beneficial to use UDP to propagate information). what do you think about GHOST?
Also I got interesting idea, but I’m not sure how it would work in practice...
3. Lack of Wallet. People simply got used to this. I don’t think generating Secret Key by doing SHA on a string (like Nxt is doing currently) is a good idea.
4. Curve. You’ve already written, you’d like to switch to Ed, so I guess you think the same.
A. Server as a servlet - I think this is good choice for initial implementation (before adding binary protocol, also servlet, would still be needed if one would like to have IN-BROWSER client). But I’d change one simple (and quite obvious) thing: instead of embedding type of query in json, It should be in URL itself.
-----------