Conversation
altonen
requested review from
TheQuantumPhysicist,
iljakuklic,
muursh,
sinitcin and
zorvan
|
6.3KB for the largest test contract... Do we have any ideas for the size of a "normal" contract? |
|
Also the CI has run twice and failed in different ways each time... |
|
I can't comment on the contract sizes, maybe we could try porting some famous Solidity smart contract to ink! and see how large they are. As for the test failures, are you able to get it fail consistently on your local machine? If I reduce the block time to 6 seconds and ran the tests, they work almost every time. I haven't tried running them multiple times with 1min block time because they take so long. Anyway, the error message has actually nothing to do with pools but there is a finalization error reported by Grandpa which shuts down one of the nodes and then the tests fail. |
As discussed earlier no. I can run them locally under normal conditions with a 1min/block rate with no issues. The only time I have an issue is if I force them to run in a resource constrained env. |
|
@iljakuklic just informed me that the bug (something about chain not being finalized) is reproducible with |
Looks very similar to an issue [1] which has been since closed. I am able to reproduce it with |
An up to date node-template? What commit? |
I used EDIT: |
altonen
force-pushed
the
pp-validation
branch
from
0b4d4f0 to
69ed5f1
Compare
|
This time all tests also passed |
Instead of allowing the smart contract caller to define the AccountId of the contract, fetch the value from the ChainExtension's runtime memory. This allows the programmable pool to force the smart contract to only spend its own funds.
When PP is constructing the final TX that spends the smart contract's funds, save the outpoint hashes of the vins to a separate storage. This indicates to the local node that the smart contract has spent its funds and when it receives a TX trying to spend CallPPs of a given smart contract, the outpoint hashes in the witness field can be queried from this storage and if they are found, the TX is valid (or at least the local node agrees with the TX and accepts it).
This allows the test framework to query UTXOs of the smart contract.
Prevent a contract from calling itself through the ChainExtension as the smart contract already has capabilities of calling its own functions even without the existence of the ChainExtension, makes it harder to handle contract balances correctly and makes it very easy for the user to shoot themselves in the foot by accidentally calling the function that called into the ChainExtension, effectively resulting in infite recursion (bounded by the amount of gas, obviously). If this is found to be needed, the issue can be revisited.
If the UTXO transfer from contract to P2PK or contract succeeds, zero the balance of the smart contract as the contract no longer holds any funds.
Implement functional tests for PP and create assets directory which contains all smart contract related files
altonen
force-pushed
the
pp-validation
branch
from
69ed5f1 to
661f654
Compare
| value=1, | ||
| destination=utxo.DestCreatePP( | ||
| code=os.path.join(os.path.dirname(__file__), "assets/pooltester.wasm"), | ||
| data=[0xed, 0x4b, 0x9d, 0x1b], |
There was a problem hiding this comment.
Selector (like function ID) for the constructor so the Wasm VM knows which function to call when it's instantiating the smart contract. It was a hard lesson to learn that you must always provide a selector..
There was a problem hiding this comment.
These are Selectors pointing to pooltester.json file (i.e "selector": "0xed4b9d1b")
4 participants
This PR adds functional tests for programmable pools and implements an ECTL-type solution familiar from the Qtum whitepaper (the implementation of the ECTL replacement is done only after the testnet).