Conversation
clangenb
added
A0-core
| } else { | ||
| AccountData::default() | ||
| }; | ||
| let account_data = api.get_account_data(&accountid).unwrap().unwrap_or_default(); |
There was a problem hiding this comment.
We have changed the implementation. It returns now, our AccountData instead of the one from the api-client. This simplifies some things.
| pub struct ExtrinsicsFactoryMock<C> { | ||
| _phantom: PhantomData<C>, | ||
| } |
There was a problem hiding this comment.
Can't derive default if the concrete type doesn't implement default. This is a well-known rust bug, and we have to implement default manually.
| rpc::{tungstenite_client::TungsteniteRpcClient, Error as RpcClientError}, | ||
| }; | ||
|
|
||
| pub type ParentchainApi = Api<ParentchainRuntimeConfig, TungsteniteRpcClient>; |
There was a problem hiding this comment.
I removed this type to prevent ambiguities. We use IntegriteeApi, TargetAApi, TargetBApi in all cases now, or we are generic over traits.
clangenb
changed the title
# Conflicts: # Cargo.lock # enclave-runtime/Cargo.lock
|
testing with
observations: If I don't specify target_b as shielding target:
If I do specify shielding-target = target-b:
Therefore, the enclave IS capable of sending extrinsics to target_b Asset Hub! Next, let's see if shielding works:
edit: reproducing the above leads to varying outcome. there seems to be some race condition: tried to send 9mROC. balance of enclave account was 26mROC. proxy deposit base is 0.66 mROC next try gets one step further: yet, proxy.ProxyAdded doesn't happen. xt got swallowed It can even happen that the first funding extrinsic fails: |
|
seems we see this very often. most likely the cause why scanning blocks for shielding trasnfers fails as the block doesn't even get processed: Guess we need to change the pruning mode of the collators and validators in zombienet: But the problem is another one: the initial sync imports until block 8 and the next light client import is block 14. see https://gist.github.com/brenzi/6a2cb568c41d1e437834dc745ae15904 hypothesis:
|
| let xts = vault_extrinsics_factory.create_extrinsics(&[(call, mortality)], None)?; | ||
|
|
||
| ocall_api.send_to_parentchain(xts, &parentchain_id, false)?; | ||
| ocall_api.send_to_parentchain(xts, &parentchain_id, true)?; |
There was a problem hiding this comment.
this may help to not accidentally use the proxy before it got created fine
There was a problem hiding this comment.
or maybe waiting for confirmations in the enclave blocks parentchain sync?
| use itp_types::parentchain::ParentchainCall; | ||
| pub use peer_block_sync::*; | ||
|
|
||
| pub trait Verifier<ParentchainBlock, SignedSidechainBlock>: Send + Sync |
There was a problem hiding this comment.
all the sidechain stuff effectively only needs the header which is of equal type for all parentchains. Tried to untangle the mess....
|
So, interestingly, this commit 5698d95, which reverts another commit from this branch makes creating the proxy account work 5 out of 7 times, the initial funding has always worked. This unfortunately implies to me that we have a timing related issue. When it failed, I also got the ancestry error. Below are the logs of a success and a failed run. I will analyze them later. |
|
We still get header ancestry errors, this grep of the log seems very suspicious: The only way I can see that this makes sense is here: worker/sidechain/consensus/slots/src/lib.rs Line 250 in 410e2ca Edit: Ok this makes sense actually. Whenever there a parentchain block in the queue we can peek it (and get the number > 8), and then we fail to import it due to the ancestry rematch. Whenever there is nothing in the queue, we return the last finalized from our light client db. |
|
the following command yields: clear && less worker.log | grep -C 2 "filter"
[2024-12-18T16:09:13.286758Z TRACE itc_parentchain_indirect_calls_executor::executor] xt_statuses:: [Success, Success, Success]
[2024-12-18T16:09:13.286864Z TRACE itc_parentchain_indirect_calls_executor::executor] extrinsic count :: 3
[2024-12-18T16:09:13.297792Z TRACE ita_parentchain_interface::integritee::event_handler] filtering transfer events to shard vault account: 0x9974260cb3a4d525a6f192b709796569799dabd983f1a5448d94fdd014ce4aab
[2024-12-18T16:09:13.298754Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [1, 0]
[2024-12-18T16:09:13.298839Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [3, 0]
--
[2024-12-18T16:09:15.511606Z TRACE itc_parentchain_indirect_calls_executor::executor] xt_statuses:: [Success, Success]
[2024-12-18T16:09:15.511709Z TRACE itc_parentchain_indirect_calls_executor::executor] extrinsic count :: 2
[2024-12-18T16:09:15.516665Z TRACE ita_parentchain_interface::integritee::event_handler] filtering transfer events to shard vault account: 0x9974260cb3a4d525a6f192b709796569799dabd983f1a5448d94fdd014ce4aab
[2024-12-18T16:09:15.517353Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [1, 0]
[2024-12-18T16:09:15.517405Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [3, 0]
--
[2024-12-18T16:09:27.358944Z TRACE itc_parentchain_indirect_calls_executor::executor] xt_statuses:: [Success, Success, Success, Success, Success]
[2024-12-18T16:09:27.359011Z TRACE itc_parentchain_indirect_calls_executor::executor] extrinsic count :: 5
[2024-12-18T16:09:27.378990Z TRACE ita_parentchain_interface::integritee::event_handler] filtering transfer events to shard vault account: 0x9974260cb3a4d525a6f192b709796569799dabd983f1a5448d94fdd014ce4aab
[2024-12-18T16:09:27.379532Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [1, 0]
[2024-12-18T16:09:27.379572Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [3, 0]
--
[2024-12-18T16:09:39.311636Z TRACE itc_parentchain_indirect_calls_executor::executor] xt_statuses:: [Success, Success]
[2024-12-18T16:09:39.311657Z TRACE itc_parentchain_indirect_calls_executor::executor] extrinsic count :: 2
[2024-12-18T16:09:39.315628Z TRACE ita_parentchain_interface::integritee::event_handler] filtering transfer events to shard vault account: 0x9974260cb3a4d525a6f192b709796569799dabd983f1a5448d94fdd014ce4aab
[2024-12-18T16:09:39.316180Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [1, 0]
[2024-12-18T16:09:39.316199Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [3, 0]
--
[2024-12-18T16:09:51.409562Z TRACE itc_parentchain_indirect_calls_executor::executor] xt_statuses:: [Success, Success, Success, Success, Success]
[2024-12-18T16:09:51.409676Z TRACE itc_parentchain_indirect_calls_executor::executor] extrinsic count :: 5
[2024-12-18T16:09:51.440125Z TRACE ita_parentchain_interface::integritee::event_handler] filtering transfer events to shard vault account: 0x9974260cb3a4d525a6f192b709796569799dabd983f1a5448d94fdd014ce4aab
[2024-12-18T16:09:51.441618Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [1, 0]
[2024-12-18T16:09:51.441677Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [3, 0]
--
[2024-12-18T16:10:03.333112Z TRACE itc_parentchain_indirect_calls_executor::executor] xt_statuses:: [Success, Success, Success]
[2024-12-18T16:10:03.333135Z TRACE itc_parentchain_indirect_calls_executor::executor] extrinsic count :: 3
[2024-12-18T16:10:03.342183Z TRACE ita_parentchain_interface::integritee::event_handler] filtering transfer events to shard vault account: 0x9974260cb3a4d525a6f192b709796569799dabd983f1a5448d94fdd014ce4aab
[2024-12-18T16:10:03.342647Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [1, 0]
[2024-12-18T16:10:03.342660Z TRACE ita_parentchain_interface::integritee] ExtrinsicFilter: attempting to execute indirect call with index [3, 0]Which is missing logs from target b even though there should be logs too. So I guess we are missing something in the initialization of target b |
|
I reproduced the current state. It seems that the service and the enclave regularly - but not deterministically fail to send extrinsics. Be it service or enclave, they fail with txStatus "Invalid" Also, I tested that the initial sync isn't disturbed by a transfer extrinsic which happened before registering the enclave (not such a surprise as we don't scan these blocks) |
|
@clangenb your plan made sense: I removed AssetTip customizations and tried running target_b = relaychain as shielding target.
Same ancestry mismatch issues. Next step: try the same with master and see if the issue was already there before this PR |
|
there seems to be a problem on master too: We get |
|
So, on master the bug doesn't happen for target a, does it? So maybe we want to test that target a still works on this branch? |
|
The race condition might imply that something from target a writes to target b's storage, and depending on whether this already happened, funding the enclave works or not. What do you think? Edit: or the integritee parentchain writes to target b. |
brenzi
left a comment
brenzi
left a comment
There was a problem hiding this comment.
I tested this with
zombienet-linux-x64 spawn --provider native zombienet/rococo-local-with-integritee-and-asset-hub.toml
./integritee-service -c -u ws://172.17.0.1 --target-b-parentchain-rpc-url ws://172.17.0.1 --target-b-parentchain-rpc-port 9954 --ws-external --enable-metrics run --skip-ra --dev --shielding-target target_b &> worker-ah.log
shielding and unshielding to/from Asset hub works!
2 participants
This was mostly accomplished introducing additional type parameters, or generics to support config discrepancies.
Other changes:
ParentchainApito prevent ambiguities. We explicitly use nowIntegriteeRpcApi,TargetARpcApi, TargetBRpcApi`, or just have generic type parameters.Testing Against Asset Hub:
Critical line from above log:
[2024-11-26T18:03:54.497Z WARN substrate_api_client::rpc::tungstenite_client::client] Expected subscription, but received an id response instead: Object {"error": Object {"code": Number(1010), "data": String("Transaction has a bad signature"), "message": String("Invalid Transaction")}, "id": String("1"), "jsonrpc": String("2.0")}Bad signature error, we can fund the enclave account from Alice. So our extrinsic handling concept is ok, but I have to double check the extrinsic factory code in the enclave side, which is producing the signature.