search

aionnetwork / AVM

Enabling Java code to run in a blockchain environment
https://theoan.com/
MIT License
49 stars 25 forks source link

Discuss using a constant/configurable class #300

Closed aionbot closed 5 years ago

aionbot commented 5 years ago

Issue created by aionick (on Friday Nov 02, 2018 at 15:09 GMT)

What I mean by this is a class in the Avm dedicated to holding constants that may be of value to the outside world, or even a place where internal Avm settings may be configurable by the outside world.

Such a class may become valuable as we get further into the kernel integration (probably actually very late into it), and it may be worth discussing how to handle these two goals.

An example of a constant we will want to leak is the avm contract prefix. Since the avm creates contracts and sets a specific prefix so that the kernel can later detect which vm to use easily, the kernel will want to see this value somehow (currently using NodeEnvironment for this). We also might want some configurations on the number of threads the avm uses, etc.

aionbot commented 5 years ago

Comment by jeff-aion (on Friday Nov 02, 2018 at 15:16 GMT)

This is a good idea, especially related to how the kernel-VM assumptions need to be communicated. On that front, it is something we should do as soon as we know how we want the dependencies to work (essentially, this should go along with the interfaces which both sides of the divide need to agree on).

Internally to the AVM, we could do something like this, now. We currently have PackageConstants to handle the prefixes we use for remapping so we either need something, along-side that, for more generic internal constants (including the ones we eventually need to migrate into that cross-module location) or maybe we should roll PackageConstants into that more generic class, too.

Anything that can give context/definition to "magic constants" we use throughout the codebase would really help us keep the scope of this containable.

jeff-aion commented 5 years ago

Note that the constant from 0d65841a2cdf4acf9b4adb3052a9d1ba3347a1c2 will not be exposed through this new configuration object as we have decided the contract prefix distinction is being removed.