Ethereum Client Parity Improves Support For Encrypted Smart Contracts

By Hannah May 21, 2018 Digital Currency No Comments

In its latest software update, ethereum client Parity has updated support for on-chain private transactions, giving developers the opportunity to create and install encrypted smart contracts.

Introduced on Tuesday, Parity 1.11.1-beta come with numerous features to the software client, which is still popular regardless of the fact that numerous bugs in Parity’s multisig smart contract libraries have given the company issues, resulting to users losing access to huge amounts of funds.

The focal attention in the new feature released is the support for private transactions, which permits developers to encrypt smart contracts. The basic code is stored in a private contract, which is permissioned and hence not publicly visible, the private contract is then wrapped in a public contract, making it possible for authorized users to connect with it on-chain without revealing the private contract’s code.

According to the release notes:

“Private Transactions make it possible for you to store, modify, and view code and state for a set of permissioned participants. This means that with private transactions on public chains, all contracts and transactions are accessible only by those with the right permissions viewable by anyone, but now you can work with others in the open behind strong encryption.”

Another explanation given on Reddit by Parity developer Maciej Hirsz states:

“Private Transactions are basically Private Contracts, where the state and the code of the contract are both encrypted. The transaction is first sent off-chain to a number (specified by the contract) of Validators that all have to agree on what the new state is, then you take the new encrypted state with signatures of all of the Validators to update it on-chain. Key sharing is enabled using a threshold cryptography scheme that enables certain parties to be permissioned to securely receive key parts from what we call Secret Store.”

The first release came with numerous limitations, including the potential to carry out one private transaction per block per contract. Besides, there is not presently a way to configure the number of validators must verify private transactions, hence all validators must do so under the present structure.