From d12eb9e4870c39843a2291c0bea31a03ab1246be Mon Sep 17 00:00:00 2001 From: Jay Geng Date: Mon, 9 Sep 2024 15:12:10 -0400 Subject: [PATCH] (minor) CAP-59: tweak language (#1547) --- core/cap-0059.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/core/cap-0059.md b/core/cap-0059.md index 52e01875f..34dc8086a 100644 --- a/core/cap-0059.md +++ b/core/cap-0059.md @@ -21,7 +21,7 @@ BLS12-381 is a pairing-friendly elliptic curve which enables a new suite of appl As described in the preamble section. ## Motivation -Pairing friendly elliptic curve operations are the backbone of many advanced Zero Knowledge (ZK) constructions, with a wide array of applications ranging from scaling, to identity management and privacy preserving solutions. +Pairing friendly elliptic curve operations are the backbone of many advanced Zero Knowledge (ZK) constructions, with a wide array of applications ranging from scaling to identity management. BLS12-381 is one of the most well-known and widely adopted pairing friendly curves, due to its efficiency and 128-bit security. However, the curve operations are inherently computationally intensive, making them prohibitive to be implemented in a smart contract. Providing an efficient implementation for a well-chosen set of curve and field operations natively inside the Soroban host is crucial for unlocking zero knowledge functionality in smart contracts @@ -623,7 +623,7 @@ The new metering [cost types](#new-metering-costtypes-introduced) broadly follow #### Encode/Decode The only two cost types representing encoding/decoding are of the base field element `Bls12381EncodeFp` and `Bls12381DecodeFp`, since all field and group elements can be composed of the base elements. (En)Decoding `G1` is (en)decoding two `fp` separately, same for `fp2`. `G2` contains two `fp2`, that are (en)decoded separately. `fr` is also represented as a field element of a less order, thus (en)decoding work is strictly less than on an `fp` (and thus okay to use `fp` as an moderate overestimation for it). -All of our encoding/decoding rules follows the original [Zcash standard](https://github.com/zcash/librustzcash/blob/6e0364cd42a2b3d2b958a54771ef51a8db79dd29/pairing/src/bls12_381/README.md). +Our encoding/decoding follows the original [spec](https://github.com/zcash/librustzcash/blob/6e0364cd42a2b3d2b958a54771ef51a8db79dd29/pairing/src/bls12_381/README.md). #### Contract panic on error While not particular to, or introduced by this proposal, it is important to point out that if any error occurs whiling calling a host function, the host will trap the guest VM, which terminates the execution of the guest contract. A host error can span a wide range of reasons, such as running out-of-budget or trying to access an invalid object reference, most of which aren't recoverable for the contract (the [`try_call`](cap-0046-03.md/#call-host-functions-mod-d) function allows calling a contract function in fallible ways, i.e. return `Void` on non-internal errors). This design is to ensure the integrity of the execution runtime (see [cap-0046-01](cap-0046-01.md/#interface) and [cap-0046-03](cap-0046-03.md/#error-handling) for details).