introduce devmode for development about aeplugin_dev_mode HOT 5 CLOSED

By time

• PUT /devmode/time

  • Request payload example {"value": 86400} (amount of seconds to move forward)

@bogdan-manole this is the one you currently miss, right? I don't think we followed my proposal back then. but most of the stuff has been added already.

let me try to summarize what's done (which has also been added by @uwiger independent of the issue here) and what's missing 😅

Current State

• Config
  • chain
    • keyblock interval
    • microblock interval
    • auto-emission of microblocks
    • start_time - unix timestamp to start with the first (or ongoing) block
      • default: current unix timestamp
    • protocol_version - protocol version to run the node with (hard_forks section should be omitted)
      • default: always the latest hardfork
    • block_height_start - height to start the creation of blocks at
      • only relevant if the node is started using a snapshot.
      • default: following block based on the latest block of the snapshot
  • accounts
    • derive_from_mnemonic - mnemonic seed phrase to derive accounts from (@nikita-fuchs working on that afaik)
      • default: some seed phrase we always use OR a generated one (not sure what's better @nikita-fuchs)
    • default_balance - the default balance of all generated accounts
      • default: 500 Æ
    • total_accounts - the total amount of accounts to derive from mnemonic
      • default: 10
• API
  • chain
    • /emit_mb - Emit a microblock
    • /emit_kb?n=<N> - Emit N keyblocks
    • /kb_interval?secs=<S> - Set a keyblock interval of S seconds (secs=0 turns off)
    • /mb_interval?secs=<S> - Set a microblock interval of S seconds (secs=0 turns off)
    • /auto_emit_mb?auto_emit=on - Turn on auto-emission of microblocks on tx push
    • /auto_emit_mb?auto_emit=off - Turn off auto-emission of microblocks on tx push
    • time?secs=<S> - Jump S seconds into the future
    • protocol_version=<V> Jump to the (future) protocol version V

Other considerations

• did somebody ever test running devmode based on a mainnet/testnet snapshot? @nikita-fuchs @thepiwo
• we recently also discussed if we can fund a new account after we run in devmode based on a mainnet/testnet snapshop. it should already be doable but somebody needs to test @nikita-fuchs @thepiwo
• impersonating accounts when running devmode based on a mainnet/testnet snapshot -> how can we get control over an account where we do not know the private key? @uwiger @velzevur @hanssv

from aeplugin_dev_mode.

seems like naming could change as devmode is probably the better naming for this

from aeplugin_dev_mode.

Hello @marc0olo! I have to say, great proposal, very thorough!

Have you seen this issue? aeternity/aeternity#3545
It's a simple maintenance/debug mode, but can it be useful for smart-contract developers also?

from aeplugin_dev_mode.

Hello @marc0olo! I have to say, great proposal, very thorough!

Yeah smart contract devs really need this kind of functionality. Details can - of course - be changed if it makes sense.

Have you seen this issue? aeternity/aeternity#3545
It's a simple maintenance/debug mode, but can it be useful for smart-contract developers also?

No I haven't seen it before. It seems like there is at least some overlap when it comes to deactivating sync e.g.. And we don't need to be able to switch to devmode during runtime (if this is required for maintenance mode). Also it's not only about deactivating mining and http endpoints. In case of the devmode we need to completely change the consensus and still allow transactions to be broadcasted via the http endpoints like usual.

from aeplugin_dev_mode.

closing in favor of #20

from aeplugin_dev_mode.