Osuke
Osuke
Enclave暗号鍵ペアの生成もrngに基づいて生成するため、`common` に移動 https://github.com/LayerXcom/anonify/blob/master/frame/sodium/src/rng.rs
リトライ期間後にkey-vaultノードが復旧するなどで、成功するパターンがある。イベントを処理するときに発生するエラーパターンとしてデフォルトではエラーが発生したらそのイベントはスキップする（状態遷移時のエラーなど）が、例外的にスキップしないことを示すエラー型を返せるようにする。ここでのエラーは、この例外的なケースで、handshakeの処理をせずに次のイベント処理はできずkey-vaultノードがavailableになるまでスタックする挙動が適切。 https://github.com/LayerXcom/anonify/blob/398385a9b9c61d1f5f489b577121f38249c04e0d/frame/treekem/src/group_state.rs#L102-L114
`SealedEnclaveDecryptionKey`をレスポンスするように修正 https://github.com/LayerXcom/anonify/blob/c8a926a50c1bd302bbc964050d5ed5ed915282ac/frame/sodium/src/sealing.rs#L26-L32
https://github.com/LayerXcom/anonify/blob/c0e6c75f01bc5c51d0da0d089e665812b6642c0b/frame/common/src/crypto.rs#L520-L521
State-runtimeノードは事前に定義された`roster_idx`の順番にグループ参加する必要がある。 異なる順番で参加した場合はオンチェーン検証でrevertするので、このエラー検出が正しくされうるかのテストケースを追加する。 ケース例 * 最初のメンバーとしてroster_idx=1のノードが参加 * roster_idx=1のノードが参加するはずが、roster_idx=2のノードが参加 https://github.com/LayerXcom/anonify/blob/master/nodes/state-runtime/server/src/tests.rs
パフォーマンス改善のためBCノードから取得したイベントを非同期に処理する。以下2つのパターンが考えられる。 * threadA(polling BC node) --> channel --> threadB(ecall) * threadA(polling) --> channel --> threadB(formatting) --> channel --> threadC(ecall) 前者について、threadAは固定間隔でBC nodeからイベントを取得し適切に整形し、channelに流すところまでを責務とする。ThreadBはそのchannelからイベントを取得し、ecallを随時実行していく。 ここにおけるchannelは順序制御のためにSPSCでなければならない。
参考：https://scrapbox.io/layerx/Remote_Attestation
Groupkey暗号化からTxがブロックに取り込まれるまでの間に順序が変更してしまうと、以下でrevertが発生する。以下のrevertが発生した場合は、それをStateRuntimeノードで受け取り、再度GroupKeyで暗号化してTx送信する。そのためには、StateRuntimeノードのhost側に `RequestId => クライアント暗号文`の形式で一定期間キャッシュしておき、revertメッセージにRequestIdを含める必要がある。 https://github.com/LayerXcom/anonify/blob/0284be4edbc27a494397bfd440db8b432effbec0/contracts/Anonify.sol#L134-L141
エラーが返ることによりイベント処理がアトミックに処理されないケースの対処。 StateRuntimeノードはhost側とEnclaveに状態を持っているので、イベント処理の途中でエラーが返り、後続の処理が行われないケースにおいて状態不整合が起こりえる場合がないか、チェックする。 検証例としては、以下のようなEnclave処理の順番の正しさなどを確認 https://github.com/LayerXcom/anonify/blob/38064280054d3e314193990bd48dc4e9e0a5fd56/modules/anonify-enclave/src/commands.rs#L101-L130
Handshake送信時もCommand送信時同様に、オンチェーンからイベントを取得する前に次のTxを送信可能なように（receiverとは別に）sender用のグループ状態を持っておき、`group_key.process_handshake` を進める必要がある。 例えば、 (generation, epoch): (3,1) -> (4,1) -> (0,2) をイベントを取得せずにTx送信時に状態を進めたとすると、次のcommand送信時は (1,2) であるべきだが、現状のsender用のhandshakeグループ状態を持っていない場合だと (5,1) を送信してしまう。 これによりHandshake送信以降のTx送信はオンチェーンの`GroupKeyCounter`検証でrevertしてしまう。（Handshakeをイベントとして取得し状態を更新しているケースでは問題ない） https://github.com/LayerXcom/anonify/blob/38064280054d3e314193990bd48dc4e9e0a5fd56/modules/anonify-enclave/src/handshake.rs#L67-L73