Add a check in verify_transaction() to reject transactions that have a
number of calls greater than the GAS_LIMIT defined in the runtime.
This prevents a potential denial-of-service vector where an attacker
could submit extremely large transactions that are guaranteed to revert
but still tie up system resources before the revert happens.
This commit handles cases where the wasm functions had no return values.
- The code has been rewritten to avoid potential index out of bounds
errors when the `ret` variable could have had a length of zero
- Added new debug message to signal when a contract has returned no
values, but this is expected and desirable
- Add code comments
This commit explicitly handles a scenario where an underflow could
occur when calculating gas. In practice, this should not occur as the
WASM points budget should be synchronized with the contract's gas usage.
For this reason, the code should panic instead of underflow if this does
somehow happen.
This prevents double-voting in the sense of minting new coins _after_
a proposal was created, meaning only the coins that have existed prior
to creating a certain proposal are able to vote on it.
This is done by marking down the latest Merkle root in the Money state
and attaching it to the proposal's metadata. Then this root is used for
verifying inclusion proofs when voting.
Also migrate all the contracts that use merkle_add to this API.
This is the better approach, since it avoids having to run redundant
operations like lots of hashing when we want to retrieve the latest
Merkle root in some tree. It is too expensive to do it directly in WASM,
so doing this through the injected host function allows us to price it
more accordingly.
This allows us to use a sled-overlay over the original Blockchain sled db, so we can validate transactions execution without actually writting to it. Tests pass, but its far from ready. Cleaning, some todos and erroneous txs handling still missing.
This is used specifically for zkas circuits bundled with the WASM
contracts. If necessary, the functions will also create and serialize
VerifyingKey objects needed to verify proofs using the given circuit
and store them in the database for later reference.
We rely on the assumption that `deploy()` will do the db init or
lookup before running so the zkas db handle is always index zero.
