[BUG] kernel.blockTimeLessThan bricks deployed contract

[a-kyras]

Context & versions:

MacOS. Using standalone local network for testing smart contract.

% compact --version && compact list -i  
compact 0.2.0
compact: installed versions

→ 0.26.0

Used ts packages:

    "@midnight-ntwrk/compact-runtime": "^0.9.0",
    "@midnight-ntwrk/ledger": "^4.0.0",
    "@midnight-ntwrk/midnight-js-contracts": "^2.0.2",
    "@midnight-ntwrk/midnight-js-http-client-proof-provider": "^2.0.2",
    "@midnight-ntwrk/midnight-js-indexer-public-data-provider": "^2.0.2",
    "@midnight-ntwrk/midnight-js-level-private-state-provider": "^2.0.2",
    "@midnight-ntwrk/midnight-js-network-id": "^2.0.2",
    "@midnight-ntwrk/midnight-js-node-zk-config-provider": "^2.0.2",
    "@midnight-ntwrk/midnight-js-types": "^2.0.2",
    "@midnight-ntwrk/wallet": "^5.0.0",
    "@midnight-ntwrk/wallet-api": "^5.0.0",
    "@midnight-ntwrk/zswap": "^4.0.0",

Steps to reproduce:

1. Created this smart contract

pragma language_version >= 0.18.0 && < 0.19.0;

import CompactStandardLibrary;

constructor() {
}

export circuit blockTimeWithinBounds(lower: Uint<64>, upper: Uint<64>): [Boolean, [Boolean, Boolean]] {
  const withinLowerBound = !kernel.blockTimeLessThan(disclose(lower));
  const withinUpperBound = !kernel.blockTimeGreaterThan(disclose(upper));
  return [withinLowerBound && withinUpperBound, [withinLowerBound, withinUpperBound]];
}

2. I deployed this to the local standalone network
3. Called the blockTimeWithinBounds with arguments: [0, 18446744073709551615] Got result [true, [true, true]]
4. Went to Epoch Converter and copied the current Unix epoch time.
5. Called the circuit with arguments [<copied unix epoch time>, 18446744073709551615] => Transaction failed with error:

{
        "circuitId": "timeBlockWithinBounds",
        "tx": {
                "__wbg_ptr": 1398672
        },
        "status": "FailEntirely",
        "txId": "000000000f62bcd4e401da0e1186eaadba3c072e84ab4632d2ee8d265eb6f343813aa0dd",
        "txHash": "db57b7000d27161d6aec92cbf11a5fdb96d9b04d3d3410c50cf41df56f9804bd",
        "blockHeight": 4978,
        "blockHash": "35bfb99de7e231b871ebfddbebfb2b184e91695b26656f8259b1b82a939ded00"
}
    at submitCallTx (./node_modules/@midnight-ntwrk/midnight-js-contracts/src/submit-call-tx.ts:67:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async main (./main.ts:41:14)

6. Called the blockTimeWithinBounds with arguments: [0, 18446744073709551615] again. Got error:

Unexpected length of input
    at __wbindgen_error_new (./node_modules/@midnight-ntwrk/ledger/midnight_ledger_wasm_bg.js:7821:17)
    at wasm://wasm/0152566a:wasm-function[4615]:0x4fea6e
    at wasm://wasm/0152566a:wasm-function[2684]:0x421cc8
    at wasm://wasm/0152566a:wasm-function[4285]:0x4c1604
    at ZswapChainState.deserialize (./node_modules/@midnight-ntwrk/ledger/midnight_ledger_wasm_bg.js:7183:26)
    at deserializeZswapState (./node_modules/@midnight-ntwrk/midnight-js-indexer-public-data-provider/src/indexer-public-data-provider.ts:93:19)
    at Object.queryZSwapAndContractState (./node_modules/@midnight-ntwrk/midnight-js-indexer-public-data-provider/src/indexer-public-data-provider.ts:385:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async getPublicStates (./node_modules/@midnight-ntwrk/midnight-js-contracts/src/get-states.ts:48:5)
    at async getStates (./node_modules/@midnight-ntwrk/midnight-js-contracts/src/get-states.ts:73:32)

Note

If contract contain multiple circuits, if the transaction fail happens, all of them would fail onwards with same error, not just the one that triggered it.

Actual behavior:

Calling circuit bricks deployed contract.

Expected behavior:

Circuit returns value true or false, or in worst case fails. Do not bricks contract.

[a-kyras]

Additional info to this. I checked the output of the queryZSwapAndContractState, without deserializing the ZSwap state. And it seems that the state itself dissappeares:

Here are output (but for different contract, on which I noticed this behaviour):

{
  zswapState: '000400030041000000000000000000000023000000022002d94c1364952b3efe0f23ec4789babb07b6368cc7040b3a5043ac96849ec4550500000000230000000220dccacef79604329d2127edfc7f47c0263601ac27dd548d0423e4598e37bce9530400000000230000000220e79f0547250085db2ab6c15c02560149b4090ed912c7fd4a5bded2b8f977466e030000000022000000021fa44a6f78d4484606d84a7a3d32a24c1c3eec39930f3d09fbd5a63f97ab82d7000000000002000000010002000000200000004f6138662095d5b743586b6c8e858987fd0c6ca3a180e5c6d89e86048c8e4f9320000000771042ab19903664f075c65613976a8e20dfa482966ab505d6695e84ade772f523000000032024d6ad3fbc563d27cb386ed2ba3fc7895db993a98469936fcee3474428fa8c5001000000000200000001010200000020000000e1e8601a2c9676878d20b4303546e3e9605a87770488ed6739ddf02473900ab820000000ea8af56c091b08cd89859ec2b8041a5e12bbb5560cd890528013ea04d041330823000000032068bf5843c8f9db8f1969802c27f0e2d09403d9ad817f1a5e87bc9402b87a92450200000000020000000102020000002000000052b17688b4f46d38055722d747e3a3ed7a1a7a18d7607ca80ce6bf13f80673242000000081540ddc172ee212bc36b7e75f7b49cbd5feaf8686065cca7a3b0a49b7fa75c52300000003200babeb0e276419d760acb0bd7c160d362a59800057f97ce1cc3b9b4b8fb54247030200000020000000f8fbd8392da7b61767d2ebc5707d4af344de58ecee76665ab3da4d4be886675b200000000ceb71c4b05fa7ad94299271a73fe21012814516465955578faabee0542027292300000003208f1eb6e8ca0ea4fe12c66b2c1a9b726893dc3fd3264ec11a2c928d119f1e29200402000000200000001a3b1525e616b5461b6295b7be5039bbb0d9849dc859f7eb28da2a07af499fa8200000000a63f102284b45128ded8a3e06c508fda5b4539bc1fb5c88b8e1b7677d707b632300000003206c128444f629dba8ba059252a233ed4668c326cc912173309ae22c48e4e5406f05020000002000000064ebdf044623420f722210f38aae60937591a603175d098a252f81637e8c6eef20000000c255de4938f3965c71d6507f0318ff3ffa02a3fb6fb5b4eb02a5d7749444096c230000000320fe58acbcbeefd34e64888c4dda3897836a1959ea0835e15eb878211746c7a53206000000000200000001060200000020000000b8b115d353ba851078bd50eae0adebcbeb21427bc7804462a90b8af5b96c2bcc20000000314ae3b1c584c66644bb228779ce78e63355bac023cf535b42b0996956abb6c3230000000320c488e98c8b83c057bfb438f2037d7d3b86545b1f6af3063118444fe9accee55d07000000000200000001070200000020000000ba36d73ac392c799dec9e257ebfba185b6cc15205f78e94a2a05d26a6d717eb020000000bca9fa41ce356548f89d4c640a876ebd3dad078757b4ca470602361f0398bb2c230000000320c377fd69eaf1ebde04312f0f45bf9d83e3627b5a4cbe67557a381d499cd1ec2008000000000200000001080200000020000000bcfea34e96264fbef4861e948cbc015ca4c858b005803b5f0374d0ef7a2c8e9320000000ee2f1397df461f01d4dcd0bdf25c8578cc122a333c5dcfeb739e19f9003acdc4230000000320025b3e3d0b2914ee04f1466df82968a10561d3091909b24037c49082dd89216a090000000002000000010902000000200000006831eb2f9781c76fe22d2ac00e0a8ba65c57328029cf640e3682cacec736e88320000000dc4271fb15a60a2f1b22560103a4da49a33d418e5d6c1282b86119bca6ae00f6230000000320cb0dedf33d1a8195187f8c23cbaaa3bc4c2040845f5408124ed05e7698c21c680a0000000002000000010a02000000200000005bd862d60ce49a32d33f69395f75d3671898b425d3988a51ab3936782faad48a200000002b5c2739f14f754263856759eee457022cb247d1ea9c07d568bf86902d5252f8230000000320a542030eff7bb965eab0c6447b166617e9a093aec831fb77d68d9d2247d12d090b0000000002000000010b020000002000000071552685b0b21bc9fbc75a1ae6f1c2493f0542997800ed7153042fe921568f7d200000009c067552d1eadd2689db8e49ceffc43e5460e0a31aacc39e23e8268e4c0ab52f2300000003205106f21c00fbcafe6c58138f879d4d430385f06b078d790d0789da080b7f8a690c0000000002000000010c02000000200000007a619bf2d3fa9adf241afbb25931ea635e62d3c0111bffdd080556e977bf1e23200000008b82106b530fc5c269b4b1cbcc7969e887bea081d3058b84ed688edbfd3930e623000000032027945ac5c65d6bd1f4aa4ea4223b219d32348f33ba6f42d540c1b6cddf85b9730d0000000002000000010d020000002000000003aee0f0036236df4d7239157a2be27528a0a25eb8ab8bf6d9fd3fd30ad8925220000000e0e80869246080e5c667d4070cc1d1077643e90bdfcc8064608c0b8f52353388230000000320c534a62975b4b4be8f798d2de47dd39a5ba80d42c4437a8eb4471b17fe091a220e0000000002000000010e02000000200000000be2f8b43ed9d82275055c5a058d4a45ad600118a032ef1d7f205a28d3a740bd20000000e423a843a7a250cedacb59a49c9085acdd1dd2f370327b5b84c1cd1acd9150342300000003203fbeb928e07cdf0f5f2bc7296d0c1c2f31e0f90c5fd52a7d2121d33a1cdd9b310f0000000002000000010f0200000020000000e82d4af6fef97ee2713e54b0784ddb232ded4ba86b6ccd5617694593a4cddf3920000000ddc1b3cf242ca9397fff0b4e1675137ad620b44ee57b65771806e06bbc5ed98d230000000320a4c51e7edafad1d14fed6313b05978f1f7dbc5c74be20ab86687d65cd364d67010000000000200000001100200000020000000ab95349edb7ace94dc241695f06371b786f46c7120c1bc1b47f664a860616f3b20000000c2f1431314e3aa568965deda70850fe3c0dc481e25a6de230cc01d483024bc79230000000320f4be168d3d258732a84ba0a754ae64ad917ea8ea44b57c4c660cfe32bbd42e19110000000002000000011102000000200000003c54a29ae53c22c246dca2a0d7332df19b7fbd4bd4acf62b75ccf055c908f6ea20000000e3a899273c6a1ba652c820ca016036dcdb935f2b77c9072e5d062dd26867c4062300000003201b4611b9cca402b3557b25d6ba1328bbe5f01071201e48297506fd72f387e9141200000000020000000112020000002000000073fcb8c6f0c08f54cc61711e6a4c68edd07ce4e51a2045a9f8d81737a95e560020000000579a7a03f9e2a61dc7fdb55bfd70e8cfe294643aea9cfcb249573bece7deb9da2300000003203ef378e9df1cddfe28044f746d3d58f71b51b1f2e245fd433e8879f693bbd221130000000002000000011302000000200000004d9aae6da283e94805fb75c9eabdc2f561b40701b902bad6f0262ef90d70fb19200000009e0bca7965a27d2041319bcf45e60b0b6e6fa1697ec627dc1ae7e18d85302b3c230000000320466325f71d4e5b13d9caf94ee46c5a746999762edf40b67b3a88e07a3d72be611400000000020000000114020000002000000084bb8f2d75c3114fe01a5ee8c16c8f7b2f8a00d0f105b919960a0ab70b3cd09e20000000f7bbb80e6123ee311dd47d32f2c6190b481ee756d84ff6182f955ff69dbef813230000000320b6ec589c3c0ac7073e843d2ff06a63110eb4e115bbe8f1ef9aeea9870a0da01b1500000000020000000115020000002000000030012101ca926aa7069b98f8118989ac1e52d128a9c801d1f38ce8ac1f9e2164200000009678187f3f5b9f344579a2c32e8e8f16f5fa83c2e50078c3c2612a22ae119d6d230000000320b1858a9d5de2cebb1510d5cc4d6172e04533327bb75d6b01bb0d505d6b338e451600000000020000000116020000002000000087c62c039e49f0bc6cfa4cbb48d5c2498d2059f9913c678a49575003241c33612000000049a19ad7d1ede7401d582459923a9d30277703889ef14c9326b90939ec1fe293230000000320c0de0c4e29fc8978e5c103539781ab269f70b0e30b1f1f59d99bd1130e69571e170000000002000000011702000000200000000a3c2a5ca876b9dbbb8c7fd90b199c0b558de477f6b65dba0f1a1ad6252a371320000000d6fce1c378a689820db92774fa8612ff880910aab47232e2db0c1742eaa0f1262300000003205186c36a9ca5aed19543e37717eff9fc6d059033fc42b97a833cb3036beb960918000000000200000001180200000020000000f9e44bc29f07b94003537f508ffb9e23f082567b3647695a5e4ac9a8360d618c20000000e765678d4a674e065b2b5b3e23a6d20ffb06ebe678aea84f585638d59e845101230000000320710adc4d93618a60d762de665279a1d1b46082f9f4399a9219d7d2b93d155a6819000000000200000001190200000020000000dea8292b81f368a90e3ea1fdbf3c1ce40a2b96181cfe76a21bdcda8189fcbdfe200000009d62169a6dbc22827b20be2691d81479ee3ff93966425ae0c6968d72caec481623000000032043ddd1214932ce7e1107bd4cf71841b91adec65fef9d07822bdf847df0123f0b1a0000000002000000011a0200000020000000332d9b354cdd5f0542bc67f71ba42552122da82601d2251f8f882fd7bcf01e9020000000a806b851939a1892d5e5c69eab4d3fa575bf23d82fbce9254a70559af7dc1309230000000320bed5fb6867f0b9e809f593651c70c5dbe60c77f999e50d7653398a8a09dded681b0000000002000000011b0200000020000000e66d41c58bdf59ec741f42163f06069de196d7de12cc5b3f7ab0581ee4b9e05c200000002ea05e45264f4caabb5440925d996f11a5e40e24d973c9fb218bee45bc40584e2300000003206d96706ed13877ff7c6a2d72cbdaac9f709213a674117c6f45851af04c85a82c1c0000000002000000011c02000000200000007b2ca2318bd6d06fa537fa48737b0cd628e02a0f1fd8ed291d7083715ade12d3200000008c55ac946a4dd4b07cd2a50dcd70b0f00d4c15bee38965f2c3cd0093ecaff82c2300000003206aa060b7a96697b20fcb049613cfb75ef6c384b94b6148e6d37bd90fe1e127291d0000000002000000011d0200000020000000ba75b6c8a548aab48138a67514782b23a706be70bdaf77fdc30d9d1ed00cc2fe20000000aadfd86a63a3890ade3a50f947d1d79e78e16d4fcf532d8f47890e67f3e7463623000000032028b93da195d6615de6fb8b81a3b3bdf3309f62a59659e5af822534a8c224704e1e0000000002000000011e02000000200000002a2517827213cf5eb4125c8269cdb4efde0e4a8f12bc3dee31ea07ac74f849822000000034cb913006d36fa19bb58f4b59b3b824195994b1c0e8cba60a436cc1b365b3b5230000000320b550bfbebd827b794d3ac972dd04d3a21138a23c4ed83f888909dfc40e2f7e2f1f0000000002000000011f0200000020000000812eb7dfd7e98848b809308547c14aec54e86f9840cf3d01cbbfc2b2a717273420000000dce3c1b054d9741da8a091f1f56a96d1f59f575272f8050f50e06db81b83974d23000000032072a3da7ff0c25f30128891e1312a914df2c9316207125435d982722f951d3373200101010000000000000000000000010000000000000000000000000101010000000000000000000000010000000001010100000000000000000000000100000000',
  contractState: 'ContractState (Array(5) [<[05]: b8>, Map {}, Map {}, <[-]: b8>, <[-]: b32>]{claim: <verifier key>, vestmentInfo: <verifier key>, createVestment: <verifier key>}ContractState )'
}

And output after:

{
  zswapState: '',
  contractState: 'ContractState (Array(5) [<[05]: b8>, Map {}, Map {}, <[-]: b8>, <[-]: b32>]{claim: <verifier key>, vestmentInfo: <verifier key>, createVestment: <verifier key>}ContractState )'
}

I dropped the indexer image, and let it sync again, with same result.

[kmillikin]

I'm not positive, but I think that the failure in your step 5 might be expected. The problem (in general) with time in the Midnight programming model is that it changes all the time. Transactions are run first off chain (with access to private data) and then again on chain (without access to private data) and the public state has to match up as far as the transaction is concerned.

This means if you see a time before some time T off chain, but you see a time after time T on chain, the transaction can fail. This is essentially the same as any other public state mismatch failure, though I agree that we should figure out a way to be more informative about the transaction failure if possible.

The second one is more concerning. It's a known bug somewhere in the stack, possibly in the indexer but that's not confirmed. So it's not exactly a Compact bug and there's not much we (the Compact team) can do about it other than try to make sure someone is looking at it.

[JosephDenman]

Thanks for reporting this. So, the issue that you mentioned about the empty ZSwap state is a known issue that occurs after a transaction has failed for a contract. We have a ticket for this and are working on it.

In step (3), you say you called the circuit with [0, 18446744073709551615] and got [true, [true, true]], was this transaction successfully validated? Or are you saying that the result of executing the circuit before submitting he transaction?

Also, it would be helpful if we knew the value of <copied unix epoch time>. The kernel assume that the time you're passing represent seconds since the UNIX epoch. If that isn't the issue, the alternative is that the node time is somehow inconsistent with real time.

[a-kyras]

In step (3), you say you called the circuit with [0, 18446744073709551615] and got [true, [true, true]], was this transaction successfully validated? Or are you saying that the result of executing the circuit before submitting he transaction?

Transaction got successfully validated and this is the result of executed transaction.

Also, it would be helpful if we knew the value of <copied unix epoch time>. The kernel assume that the time you're passing represent seconds since the UNIX epoch. If that isn't the issue, the alternative is that the node time is somehow inconsistent with real time.

The format produced on the mentioned page is seconds from unix epoch, e.g.: 1764747078

The second one is more concerning. It's a known bug somewhere in the stack, possibly in the indexer but that's not confirmed. So it's not exactly a Compact bug and there's not much we (the Compact team) can do about it other than try to make sure someone is looking at it.

Thanks for the info. Would the bug in the indexer still propagate, after fresh restart? I tried to completely wipe the indexer docker image and resync it anew, but the data was still missing.

This means if you see a time before some time T off chain, but you see a time after time T on chain, the transaction can fail. This is essentially the same as any other public state mismatch failure, though I agree that we should figure out a way to be more informative about the transaction failure if possible.

I do not understand ZK stuff that much, but if it helps. The same behaviour can be also observed without needing time from user, something similar to this. The Math_divMod is witness based division with validation, but can be the circuit can be rewritten without witness:

export circuit now(): Uint<64> {
    const [now, _] = fold(([currentNow, power], _) => {
      const [newPower, _] = Math_divMod(power, 2);
      const candidate = (currentNow + power) as Uint<64>;
      if (blockTimeGte(candidate)) {
        return [candidate, newPower];
      } else {
        return [currentNow, newPower];
      }
    }, [
      0 as Uint<64>,
      9223372036854775808 as Uint<64>
    ], default<Vector<64, Uint<1>>>);

    return now;
  }

[kmillikin]

Thanks for the info. Would the bug in the indexer still propagate, after fresh restart? I tried to completely wipe the indexer docker image and resync it anew, but the data was still missing.

I guess we don't really know. The fact that the problem persists suggests that maybe it's not the indexer after all. Anyway, it's not a Compact bug (as far as we know), it's in some other component. The people you're talking to are not the ones who can do anything about it :)

The same behaviour can be also observed without needing time from user, something similar to this.

The problem is with time, not with user input. Time changes, so a transaction that succeeds when it's run off chain can fail on chain. Transactions can fail when there's contention (imagine: you checked that I was in the "authorized" set off chain and I was, but then my authorization got revoked before the transaction was executed on chain. That transaction must fail.). Since time is constantly changing, there is always a risk of contention even if there are no other transactions.

[rongurlavi]

Quick update:
Next step - Test against latest test environment and report back expected behavior

[a-kyras]

Quick update:
Next step - Test against latest test environment and report back expected behavior

What changed? Which libraries were updated? Where are the change-logs? Which images needs updating?
Is this documented somewhere? Will this work with standalone network or just testnet?

Can you be more specific about this? Where can I check whats compatible with what?
Latest announcement on Discord is from the 4. December about new Compact release

[rooooooooob]

This might be related but I found even just calling blockTimeLte(100); anywhere in a circuit was causing it to fail with Runtime error: Pallet error: Midnight::Transaction. Even if I did nothing with the result. Omitting the line would make everything work fine. I have never been able to call any of the block time functions successfully. I would need to re-run this to see if there was more info, this was on November 8th.

I have never been able to call any of the block time functions without the circuit call failing.

This is a 100% blocker for us releasing our biggest game.

[kmillikin]

@rooooooooob what version of the Compact toolchain are using, and which network are you running your contracts on?

"Pallet error" is coming from Substrate as far as I know, which probably indicates an issue in the Midnight node.