Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

(minor) CAP-59: tweak language #1547

Merged
merged 1 commit into from
Sep 9, 2024
Merged

(minor) CAP-59: tweak language #1547

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions core/cap-0059.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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).
Expand Down
Loading