以下は、STARK の詳細なプロセスを調べるいくつかのステップです。   Step1 - Build Trace（fib2-example)  「赤」でマークされた番号は公開情報です。   Some assertion: Form: [register, step, value] examples: [0,0,1], [1,0,1], [1,7,987]   Step2 - トレースの証明者 プロトコル パラメータの選択:   pub struct ProofOptions { num_queries: u8, // number of queries to increase reliability blowup_factor: u8, // domain extension factor grinding_factor: u8, // ？nonce security parameter, for the security selection of query position hash_fn: HashFunction, // Hash Function blake3-259/192, sha3-256 field_extension: FieldExtension, // Whether the field extension is conducted fri_folding_factor: u8, // The folding factor of Fri protocol 4-8-16 fri_max_remainder_size: u8, // The max remainder of Fri protocol }   1. AIR のインスタンス化 FibAir { context: AirContext::new(trace_info, degrees, options), result: pub_inputs, } AirContext { options, // protocol parameters trace_info, // trace parameters: row number and col number transition_constraint_degrees, // transition the constraint degree, and if the multiplication of two registers is involved, then degree = 2; similarly, if the multiplication of three registers is involved, then degree = 3; if periodic column exists, then degree = base + period.length – 1 ce_blowup_factor, // constraint computational domain extension factor trace_domain < ce_domain < lde_domain trace_domain_generator: B::get_root_of_unity(log2(trace_length)), lde_domain_generator: B::get_root_of_unity(log2(lde_domain_size)), }   2. AIR とトレースの整合性を確認する (デバッグ モジュール)   2.1 基本パラメータの確認 Trace.width = air.trace_width   2.2 アサーションの正当性の検証 (境界 cs)   Trace[assertion_i.register][assertion_i.step] = assertion_i.value   2.2 トレースが遷移 cs を保持するかどうかを確認する (デバッグ モジュール)   Loop: For every two adjacent rows: pub struct EvaluationFrame<E: FieldElement> { current: Vec<E>, next: Vec<E>, } Holds: next[0] == cur[0] + cur[1] next[1] == next[0] + cur[1] The number of times of Loop: Trace.length - 1 成績証明書 write.into(air, public info)   3. トレースのためにコミットする ドメイン パラメータの選択:   StarkDomain { trace_twiddles, /ntt twiddle factor ce_domain_size: air.ce_domain_size(), //constraint computational domain ce_to_lde_blowup: air.lde_domain_size() / air.ce_domain_size(), // LDE domain domain_offset: air.domain_offset(), //domain offset }   3.1 補間 -> LDE -> LDE ドメインでの評価  3.2 コミットメント 成績証明書 write.into(cm_to_trace)   4.CS評価 4.1 線形構成係数の取得 Ok(ConstraintCompositionCoefficients { transition: t_coefficients, boundary: b_coefficients, }) 係数の数は制約の数と一致しています この例 (fib2-example) では、2 つの遷移 cs と 3 つの境界 cs があります。   4.2 t-cs および b-cs の評価者の確立 4.2.1 t-cs   1. Obtain the degree of t-cs (In this example, the degree is [1,1], refer to Chapter 2.3) 2. Establish the t-cs group (record the parameters needed for reaching the object of degree -> compose degree（ce_domain_size - 1） Loop: Calculate the evaluate-degree = base * （trace.length - 1） + tracce.length / period.cycle *(period.length - 1) of every t-cs Establish the t-cs group according to the degree: TransitionConstraintGroup { degree, // the degree of t-cs degree_adjustment, // The space to reach the object degree, target_degree = composition_degree + trace_poly_degree(vanish poly-degree), degree_adjustment = (target_degree - evaluation_degree) indexes: vec![], coefficients: vec![], } Record index and distribution coefficient “coef” Cycle each t-cs (In fib2-example, cycle twice) 3. Establish the period value table 4. Set the divisor for t-cs, with all t-cs having the same form z(x) = x^n-1 / x - g^{n-1} // The last value does not satisfy the condition   4.2.2 b-cs   1. The divisor of each b-cs is not necessarily the same 2. Judge that if the number of assertions is the same as the number of coefficients to be distributed assertion.len() == coefficients.len() 3. Establish the b-cs group Loop: Obtain the type and initial step of the assertion Establish the b-cs group BoundaryConstraintGroup { constraints: Vec::new(), divisor, // The divisor corresponding to the boundary degree_adjustment, target//The space to reach the object degree, target_degree = composition_degree + divisor.degree()，degree_adjustment = (target_degree - trace_poly_degree) } Add b-cs forms air::BoundaryConstraint { register: assertion.register, // Corresponding register index poly, // assertion value polynomial, interpolation is required for multiple values; otherwise, it is a single value poly_offset, //offset information. If the assert is in the first step, it is [0,1], otherwise it is [1, T] cc, // Coefficient distributed to this b-cs } prover::BoundaryConstraintGroup { degree_adjustment: group.degree_adjustment(), single_value_constraints: Vec::new(),// corresponding Sigle value assertion small_poly_constraints: Vec::new(),//assertion whose assertion value num is smaller than 63 large_poly_constraints: Vec::new(),//assertion whose assertion value num is larger than 63, the values in ce_domain are needed to conduct Pre_compute };   4.3 ce_domain で t/s-cs を評価する 4.3.1 評価テーブルの定義 ConstraintEvaluationTable<B: StarkField, E: FieldElement<BaseField = B>> { evaluations: Vec<Vec<E>>, //[ce_domain_size][t_cs_merge_value (0): b_cs_values(1...)] divisors: Vec<ConstraintDivisor<B>>, // [t-cs divisor, b-cs divisor] domain_offset: B, trace_length: usize, #[cfg(debug_assertions)] t_evaluations: Vec<Vec<B>>, #[cfg(debug_assertions)] t_expected_degrees: Vec<usize>, } evaluations[step_i][0] += sum_{j}(evaluation[j] * (coefficients.0 + coefficients.1 * xp) // The divisor is identical. evaluations[step_i][j] += (evframe.cur().state[register] - value) * (coefficients.0 + coefficients.1 * xp) // for single assertion evaluations[step_i][j] += (evframe.cur().state[register] - polynom::eval(&self.poly, x * self.x_offset)) * (coefficients.0 + coefficients.1 * xp) // for multiassertion // for multi-assertion evaluations[step_i][j] += (evframe.cur().state[register] - self.values[values_index]) * (coefficients.0 + coefficients.1 * xp) // for multiassertion // for multi-assertion large poly   5. CS評価へのこだわり 5.1 制約合成多項式の確立   5.2 合成ポリへのこだわり 例：  Compose_poly = a * x^3 + b * x^2 + c * x + d = (a * x^2 + c) * x^ + (b * x^2 + d) (a * x^2 + c ) と (b *x^2 +d) は、それぞれ 2 つの列に対応します。    6. DEEP 合成多項式の確立 一般形式: f(x) = q(x)* t(x) ランダムにチェックが必要 z  f(z) = q(z) * t(z)  f(x)、q(x)、t(x) は実際にそれぞれ f(z)、q(z)、t(z) に等しい Deep_composition = (q(x) - q(z)) / (x - z) を計算します。  q_q(x) の LDT をチェック 6.1 Domain(ood) の中から z which を選ぶ ドメイン外の点 z を描画します。 E の型に応じて、点は E によって定義された基本フィールドまたは拡張フィールドから描画されます。 ここで (基本フィールドではなく) 拡張フィールドからサンプリングする目的は、セキュリティを強化することです。   6.2 OOD ポイント z でのトレース多項式と制約多項式の評価 6.2.1 z & z * g での trace_poly   ood_frame = {cur: [trace_poly_0(z), trace_poly_1(z)], next: [trace_poly_0(z * g), trace_poly_1(z * g)]}   6.2.2 z における合成ポリゴン iter!(self.columns).map(|p| polynom::eval(p, z^m)).collect() // m is the column num of the composition poly   6.3 深い合成多項式の確立 6.3.1 乱数の生成 pub struct DeepCompositionCoefficients<E: FieldElement> { /// Trace polynomial composition coefficients $\alpha_i$, $\beta_i$, and $\gamma_i$. pub trace: Vec<(E, E, E)>, /// Constraint column polynomial composition coefficients $\delta_j$. pub constraints: Vec<E>, /// Degree adjustment composition coefficients $\lambda$ and $\mu$. pub degree: (E, E), }   6.3.2 カル商ポリ => for trace polynomial T`(x) = alpha * (T(x) - T(z)) // degree = trace.length - 1 T``(x) = beta * (T(x) - T(z * g)) T```(x) = gamma * (T(x) - T(z_conjugate)) merge_trace_composition_poly = T(x) / (x - z) + T``(x) / (x - z * g) + T```(x) / (x - z_conjugate) Degree = trace.lengh - 2 => for composition polynomial compute H'_i(x) = (H_i(x) - H_i(z^m)) / (x - z^m) sum(H`_i(x) * cc_i) Deep_composition_polynomial = merge_trace_composition_poly + sum(H`_i(x) * cc_i) Degree = trace.length - 2 => Deep_composition_polynomial degree adjustment Deep_composition_polynomial = Deep_composition_polynomial * (cc_0 + x * cc_1) Degree = trace.length – 1   6.4 LDE で Deep を評価する deep_evaluations<lde_domain_size> = deep_composition_poly.evaluate(&domain);   7. Deep の FRI Layer num を計算する   trace.length() = fold_factor ^ Layer_num + remainder_size; fold_factor = {4, 8, 16} remainder_size < remainder_max_size == 256   8. クエリの位置を決定する lde_domain からクエリの複数の位置を選択します。   fold_position = source_position % (fold_domain) fold_domain = source_domain / fold_factor   9. 証明対象を確立する 9.1 FRI プルーフの生成   pub struct FriProof { layers: Vec<FriProofLayer>, remainder: Vec<u8>, // last poly <all coefficients> num_partitions: u8, // stored as power of 2 } pub struct FriProofLayer { values: Vec<u8>, paths: Vec<u8>, }   9.2 上記位置のトレース ポリゴンのクエリ 上記に類似 Queries::new(trace_proof, trace_states)   9.3 上記の位置での制約ポリゴンのクエリ 上記に類似 Queries::new(merkle_proof, evaluations)   9.4 STARK プルーフの確立 StarkProof { context: self.context, commitments: self.commitments, ood_frame: self.ood_frame, trace_queries, constraint_queries, fri_proof, pow_nonce: self.pow_nonce, }   Step3 - 証拠を検証する トランスクリプトから pub-info を読み取って関連データを取得し、検証プロセスを実行します。   1. むくみチェック 5.2 章で説明した数学的関係の一貫性を検証する => for Boundary b(z) = q_b(x) * b_divisor(z) => for composition poly t(z) = q_z(x) * t_divisor(z)   2. FRI-Verifier オブジェクトのインスタンス化 pub struct FriVerifier<B, E, C, H> where B: StarkField, E: FieldElement<BaseField = B>, C: VerifierChannel<E, Hasher = H>, H: ElementHasher<BaseField = B>, { max_poly_degree: usize, domain_size: usize, domain_generator: B, layer_commitments: Vec<H::Digest>, //flod_poly commitment layer_alphas: Vec<E>, // random numbers options: FriOptions, num_partitions: usize, _channel: PhantomData<C>, }   3. クエリ位置でディープ ポリゴンを計算する 計算方法は6.4章と同じ 4. FRI VERIFY プロセスを実行する

Target

Trace

2022 - HackerNoon Contributor of the Year - Algorithms

2022 - HackerNoon Contributor of the Year - Architecture

2022 - HackerNoon Contributor of the Year - Blockchain

2022 - HackerNoon Contributor of the Year - Optimization

2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Optimization

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Nominated for 2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Blockchain

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Make resilience your competitive advantage

ああ、ただの厳しいテクニカル分析

ああ、ただの厳しいテクニカル分析

About Author

コメント

ラベル

この記事は

Related Stories

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Telegram: クリプト島と本土を結ぶ橋

暗号通貨の成長: 効果的なユーザーペルソナの作成

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Telegram: クリプト島と本土を結ぶ橋

暗号通貨の成長: 効果的なユーザーペルソナの作成

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps