(minor) CAP-59: tweak language (#1547)

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).