secp256k1-zkp API assumes that Pedersen commitments commits not just to value and blinding factor, but also to some asset or contract id, which is a 32-byte hash. Right now for that purpose we just use fixed value which is a hash of uncompressed generator point G, but it makes much more sense to use Contract Id, which will in future allow better cross-contract interaction and batch verification.
From my understanding this change should not break backward compatibility since today none of contracts can have more than one asset. Shifting the "asset id" from one value (constant) to another (contract id) must still fulfill the sum(inputs) = sum(outputs) requirement of Pedersen commitments due to homomorphic properties.
dr-orlovsky
commented
11 months ago
secp256k1-zkp API assumes that Pedersen commitments commits not just to value and blinding factor, but also to some asset or contract id, which is a 32-byte hash. Right now for that purpose we just use fixed value which is a hash of uncompressed generator point G, but it makes much more sense to use Contract Id, which will in future allow better cross-contract interaction and batch verification.
From my understanding this change should not break backward compatibility since today none of contracts can have more than one asset. Shifting the "asset id" from one value (constant) to another (contract id) must still fulfill the
sum(inputs) = sum(outputs)requirement of Pedersen commitments due to homomorphic properties.