Block and Transaction Timeouts

[kroggen]

The current method for timeout check may not be ideal

A fix is proposed on #262 but some problems are open for discussion, like this:

Contract Compilation

On V4 the smart contracts will be compiled by the aergo nodes, and some big contracts can take ~500ms to compile or even more

Contracts deployed by another contract are already compiled by the nodes on V3 and before, and these can take long time as well

This is the time for ARC1 contract factory:

time ../../aergo/bin/aergoluac --payload output.lua > payload.out

real	0m0.427s
user	0m0.425s
sys	0m0.000s

But the current method is limiting transaction execution to only 250 milliseconds, including contract compilation... that is not sufficient

We need to handle these long executions in some way

[rabbitprincess]

There are two options.

1. Increase execution time enough to compile
2. preprocess before execution time

option 1 is not possible unless increase block creation time in dpos.

[rabbitprincess]

Other option : approve compile is only in authorized site, tools, and also. for verification, authorized compiler can leave compilation evidence. ( Information that it was compiled using an verified compiler )

[kroggen]

The tools can be hacked...

Using a separate dedicated computing network would be an option, but it does not work for contracts deployed by other contracts

[rabbitprincess]

it can also be approved by aergocli or sdk only. just need auth informations.

[kroggen]

You don't need to lose your time thinking about external apps used at transaction build time

The limitation factor is:

contracts deployed by other contracts

And they are essential

[kroggen]

One workaround for contracts that deploy the same code every time:

Let the aergo engine store a map of plaincode hash -> bytecode hash

On this case a compilation would be needed only on the first time the code is deployed

The aergo engine would work like this:

1. Create a hash of the plain code
2. Check if it is on the database
3. If yes, do not need to compile. Just use the bytecode hash
4. If no:
   • Compile the code
   • Compute the bytecode hash
   • Save the map of plaincode hash -> bytecode hash

The bytecode hash is already computed, and contracts are already stored on aergo as bytecode hash -> bytecode

This is simple, but on the first time it will still take time for compilation so the protocol needs to be adapted to it

[kroggen]

If contract compilation takes so much time/resources, then the engine should charge more gas

contract.deploy() accepts both source code or another contract address

It could charge way more gas when compilation is needed and less when not needed, to encourage developers to use another contract address instead of plain code when deploying a contract

Also for the purpose of preventing a DoS attack with many deploys at the same time

[hayarobi]

The 250ms of block timeout have been set at the first of AERGO chain, and this works expectedly well almost all situations. Tx excution is canceled when the block timeout is reached since v2.4.0, but contains some bugs, which #262 fixed.#262 does not alter the specs of aergo node but preserve behaviors of previous version, actually.

[kroggen]

I am creating a test to check

[kroggen]

I added a contract compilation test on #265. It is passing on develop and also passing with your branch (tested locally)

So I suspect that the compilation time is way faster when run directly on go compared to when using aergoluac on command line

The test is deploying 6 contracts on a single transaction and it appears there is no timeout

But the integration test only covers sbp mode for now. It needs to be tested with dpos and raft as well

[kroggen]

You can merge that PR on develop, then merge develop on your branch. On this way the test will be run on your PR

[kroggen]

@gokch could work developing integration tests for dpos and raft

It can be based on the existing integration tests

I just don't know if they should be on the same aergo repo or on a separate one, because running these tests require running at least 3 nodes

At start, it can be done on the same repo on a new branch/

It may be relatively easy given the existing files. It may require copying run_tests.sh and maybe the config.toml

@kslee8282 can help as he knows how to configure the nodes

[kroggen]

I already implemented the above tests and the code is passing on dpos and raft

[hayarobi]

A simple solution is to modify the network protocol to make other nodes not overtake the BP after 2 or 3 seconds of inactivity In another words, if the current BP does not emit a block after 3 seconds, another BP can take over Most blocks would still take 1 second, but those containing deploy could take longer I don't know the details of the dpos network protocol. Is there any documentation about it?

It will result in huge works I think. It is required to change current consensus algorithm.

[kroggen]

Why a tag was created on that PR if it still has pending changes to be done?

It is better to resolve all things before, to make just a single sync test

[hayarobi]

You make sense. We have not enough time since it takes more than 3 days to complete sync test, but have enough test machines. So we do patch works and sync test in parallel. I applied your PRs #261, #263 into #262 and then began sync test again, and it will be complete about next day.

[kroggen]

Ah, OK.

I thought the sync test was taking 10-12 days