Hi everybody, nothing of the following is either announced or confirmed, but for the case it’s going to be, we need your feedback on what we came up with on these topics so far.
Please post your wishes after reading, this is your chance !
Two things of value to the æternity ecosystem which are often discussed and asked for are:
A private consortium chain implementation of the protocol with a Proof of Authority consensus
A lightweight sandbox client for developers to mess around with and quickly simulate different conditions <- probably the more interesting thing to the broad public !
Let’s give them both the codenames Ænterprise and Sændbox for now. First, I would like to share a list of possible features to both of these things and further down below picture a way how we could get to them in a cost- and resource-efficient way. Ideas and opinions welcome.
- Proof of Authority Consensus
- Special contract defines who is allowed to
- form a key block
- deploy Contracts
- call stateful functions
- transfer native tokens (once we have them)
- transfer AE (maybe?)
- who has free transactions
- and whether transactions cost gas or not at all for everyone.
These checks would need to be done by executing that contract before every other transaction execution. Not sure if our predefined contracts may hold state actually, if yes, that would be an option here, else it would need do be deployed
To comply with clients’ legal obligations and to prevent the clogging of a consortium network with free transactions, we invented an API layer which we wrapped around Ethereum nodes and combined those with an access limiter, so people could only send transactions if they had KYC authentication and didn’t exceed their limit. I know, in terms of crypto that’s bogus, but hey, they still were the sole owners of their identity (being their private key), a thing you can’t say about facebook.
A better solution to this would be allowing a treshold of gas per time which a user is allowed to use. I see difficulties to acquire the data necessary for this upon the evaluation of transactions, because that would require a lookup of past call objects which are, when querying by address, only accessible to the middleware. Or maybe someone has an idea ?
Short summary: A one-node network with pre-filled accounts that churns out (micro)blocks as soon as there are transactions (or at a preconfigured time), not utilizing PoW consensus and thus not heating up your notebook. Our wonderful Limechain guys (@MartinG, @george_lime
@aleksey.lime, who did I forget?) did the best that’s currently possible to put together something like this with what we have right now, it’s just a temp fix for the dev’s needs though.
In the Ethereum world, there is an equivalent to this that proved its usefulness several times, being TestRPC / later called Ganache or Ganache CLI. Those are far from optimal though (I have a proof that they never actually really used them in product-like scenarios, Anna and I PRed a fix some time ago that made their stuff actually not crash after running for longer than a day the first time ever), so I’d want to add some sugar we often felt the necessity for in several client’s projects. Features could be prioritized throughout the releases like so:
- Start a chain via cli with
- randomly with a predefinable balance (one for all) or
- from mnemonic with one balance for all accounts or
- a list of public/private keys with a defined amount (JSON file)
- List private keys for generated accounts upon launch + API returning the private keys (reasons further below)
- Allow defining network name
- Generate Micro blocks in the regular time like in Mainnet
- Snapshots: Save and load state based on a directory path (for easy exporting and portability) during runtime based on a key-value notation, where the
keycan be an arbitrary unique name and the assigned data containing at least
- the name of the parent snapshot
block heightof the snapshot’s creation
- and the
- Allow setting the micro block time
- Allow having micro blocks generated upon and only upon existence of one transaction (one tx / micro block)
- Allow setting hostname and port settings which to listen on (sometimes you want to have a remote team working with it, sometimes you need it local only).
- Allow creating / loading of workspaces upon start (eventually by utilizing the snapshot feature, grouping snapshots in subfolders like
and loading the latest snapshot when a workspace is chosen)
- Allow setting custom
For the graphical representation, contrary to the approach of Ganache, we should not wrap the client and the frontend in a sole application. Instead, the GUI should attach to the API of the client. This combination in Ganache annoyed us too many times, it’s a pain.
- Browser-based GUI showing accounts, their balances and option to display/copy their private keys (sometimes you quickly need to grab an account to import in the IDE or browser extension to try something out / test your application)
- Display transaction history
- Have a graphical representation of the relationship of the snapshots, essentially allowing allowing for a view in form of a tree and thereby represent forks, so to say. Clicking a branch would load the corresponding snapshot.
- Dekstop Application that launches the CLI and displays the GUI in a separate window, “electron-app style”, allowing to attach to remote sændbox
Maybe we can also get some cool graphical representation of state channel activity, which would allow for easier disguising of racing conditions and general event flow.
"And are YOU gonna implement all this ?!" - @hanssv
In order to curb the work amount necessary for all this, we should reuse as many components as possible of course. Mainly, I’m thinking about
Let Sændbox be just a configuration or build of the node client:
This is mostly meant for the non-technical side of decision making, our swedishes wouldn’t do it any other way anyway I’m sure: Maintaining Sændbox with the latest features of æternity shouldn’t come along with notable costs as it’s just “generated from” the main client and its features. Correct me please if I’m taking it too easy @hanssv @silentser?
Sharing consensus algorithm between Sændbox and Ænterprise:
If we implement some sort of Proof of Authority consensus für Ænterprise anyway, then Sændbox should simply be a one-node PoA network under the hood. The only differences that come to my mind which we would need to make are possibly in regards of the block time, but that remains to be seen.
Bundling the middleware with Sændbox, so transaction information is available to the GUI. One could also think of simply adding Sændbox-specific features to the MDW displaying them only when the MDW is used with Sændbox => a cheaper GUI
What are your thoughts, is there anything else you would love to see ?
Hope you don’t mid the long read, things need to fully come together to draw a wholesome picture.