私はここから証拠を読んでいて、技術的な(まだ重大な)問題に出くわしました。これはかなり具体的であり、コンテキストに問題があることは知っていますが、自分では理解できませんでした。
51ページと55ページでは、「標準」検証者を提示した後、分割割り当てを確認するために検証者を変更します。
最初のケース(p。51)が多項式コードに近いことを確認し、代数化(+ゼロテスター)を使用して、多項式のファミリー(Sum-(に最も近い多項式コードのコードワード)の3つの値が与えられたポイントでそれぞれ評価できる入力式に関連するプロパティを確認します。)。
2番目の場合(p。55)が近いことをチェックし、関数を特別な合計として定義します。ようなそれぞれの値が所定の時点で評価することができる(の線形関数クローゼット)。
次に、両方のケースで、ファミリー/ランダム多項式の値に対してテスト(Sum-CheckまたはTensor + Hadamard)を実行します。
私の問題は、のそれぞれの必要な値を再構築する手順は、無視できない一定の確率で誤った値を提供する可能性があることです。さらに、すべての値が正しく再構築される確率は非常に低く、定数についてはのみです。そして、これは両方の場合に当てはまります。
検証者のステップのいくつかは、ターゲット関数 /ファミリーwhpから多項式の値を取得する必要があるため、これは悪い場合があります
そのため、各「再構成代数手順」を回繰り返し使用することにより、成功確率を増幅する必要があり。
さて、ブローアップ(比較的オリジナルの検証のクエリの複雑さに)サブ・ルーチンのクエリの複雑さがより若干大きくなっていることを、この手段、それはすなわち(とは対照的に「保証された」-「望まれた」定理の声明における爆発。
これは問題なのでしょうか、それとも何かが欠けているのでしょうか(おそらくそうなのでしょうか)?