[CLOSED] Create new web3 create API for AVM

[aionbot]

Issue created by jeff-aion (on Monday Oct 22, 2018 at 18:50 GMT)

While most of the APIs used in web3 are either unrelated to AVM or can infer if AVM-specific actions are to be taken (based on inspecting high byte of address), some new ones are definitely required:

• create: the AVM contract creation is different than the FVM one so this will need its own API.
• reading storage: the object graph underlying the AVM DApp storage is completely different than the FVM key-value store so something completely new will be required here, as well.

[aionbot]

Comment by jeff-aion (on Tuesday Nov 13, 2018 at 21:40 GMT)

Specifically, we should only worry about defining, implementing, and connecting the create API, as the details of how we will read storage is going to be a longer decision, much later on.

[aionbot]

Comment by jeff-aion (on Thursday Nov 15, 2018 at 22:35 GMT)

To update this in light of recent conversations, we can't solve this with just a new API since the user needs to sign the payload which will be added to the blockchain, on their behalf. This means that there is no place for the out-of-band meta-data which we would otherwise represent as a different API entry-point.

We discussed a few ways of detecting this within the normal deployment API (since it looks like we will need to use that) and these ones seemed to be the most promising:

• check a magic number on the front of the payload (existing EVM bytecode would need to be left untouched so we would need to pick something extensible which we knew wouldn't collide, probably as a fixed-sized prefix on the JAR). Note that it sounds like eWASM is going something similar (need to find more details around the "ewasm signature" mentioned here - https://github.com/ewasm/design/blob/master/vm_semantics.md )
• specify a special destination address, which the kernel could detect as our special "deploy an AVM DApp" intention. This may be a bit cleaner as it is a large address space, is already present in every message, and re-purposes an old field instead of building a new encoding format in one we are always using in this case

[aionbot]

Comment by JunhanHu-aion (on Friday Nov 16, 2018 at 19:40 GMT)

Nothing need to be done to API for the special destination approach. Transfer this item to Nick for a kernel side implementation.

[aionbot]

Comment by aionick (on Tuesday Nov 20, 2018 at 18:26 GMT)

313 will be a first step towards completing this ticket.

[aionbot]

Comment by aionick (on Friday Nov 23, 2018 at 00:16 GMT)

Closed by a number of commits in the kernel, the core of which are: 4db17e3b642fab85bf7c57b2412fee8567eb3a32 15b66d92dc8e49bc897d052d3356a2b66f8ea282 4df36aaf837030b06fcf80455c23ac81ddbd8870 51531bb2513bfbacdb9b07b5b2cbf5d54b2b1293

as well as a few minor commits before and after, mostly doing small fixups or adding minimal, extra functionality.