Your ideas welcome ! Sandbox and Private chain!

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 ! :wink:

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 ! :slight_smile:

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.

Ænterprise

  • 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?)

and also:

  • 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 ?

Sændbox CLI

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 (@martingrigorov.chain, @george_lime
@alekseytsekov.chain, 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:

Release 1:

  • Start a chain via cli with n accounts generated
    • 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 key can be an arbitrary unique name and the assigned data containing at least
    • the name of the parent snapshot
    • a block height of the snapshot’s creation
    • and the current state.

Release 2:

  • 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 application/all_workspaces/snapshots_of_each_work_space/
    and loading the latest snapshot when a workspace is chosen)

Things I have no clear picture about yet: What implications would all this have on the functionality of state channels @uwiger @dimitar.chain ?

Release 3:

  • Allow setting custom gas limit and gas price

Sændbox GUI

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.

Release 1:

  • 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)

Release 2:

  • 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.

Release 3:

  • 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.chain
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.chain @sergei.chain?

  • 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.

Nikita

4 Likes

I made it to the end, there should be a badge for that :wink:

From the existing node perspective most of the work that is necessary would be to make a flexible PoW/PoA binding. Exactly how that should be done can be discussed, for the Enterprise case you need something more advanced than the Sandbox case - but if the advanced thing exists it can be used in the simpler case. This is the way to go, as you say, since it would be “automatically” kept up to date. The Sandbox client would just run a (carefully configured) node and interact with it to add accounts, etc.

For access to the transactions using the Middleware is good I think. An alternative is to add some transaction dumping/exporting to the node - this would be doable on a test-scale, it isn’t feasible for a complete chain where you need something properly made, i.e. the Middleware.

I’m in vacation mode, so more things might come to mind later…

2 Likes

Your badge @hanssv.chain :medal_military::smiley:

I agree with all of that, also like with the transaction dumping idea, maybe that could bring some exciting insights. What about the snapshotting and hot-reloading of state, is that going to be doable easily? The purpose of this is passing data to others for debugging, for example, or copying existing stuff to some remote testing environment.

1 Like

This wouldn’t be an issue for state channels, I think. They simply subscribe to transaction- and block events and view ‘time’ as the progression of the chain - i.e. number of key blocks until confirmation or end-of-dispute. And these parameters are configurable per channel.

1 Like

Great idea.
I like the concept to have Sændbox a pre-configured instance of Enterprise Chain. This would keep things together and ensure we don’t miss any features etc…

Also, for clarity and simplicity, I wouldn’t use Sændbox name, and choose something easier, like Dev Chain, Dæ Chain … (there is always a problem with letter “æ”). Ænterprise looks & sounds cool though.

Also I think it’s ok to skip the GUI for the moment. Do we really need it? I would prefer to have the “private chain” functionality to be released sooner than later. BTW: GUI could be an interesting community project.
Instead simple CLI is easier to implement and more powerful.

1 Like

thanks!

sure, the GUI is scheduled a little further down the road.