Roadmap Spotlight #5: New Smart Contract Features

Roadmap Spotlight #5: New Smart Contract Features

As we continue to see development occurring on our blockchain, we are always on the lookout for feedback on how to improve our platform, either to make it easier for developers to develop on, or to add new functionalities to help improve the product offering by the teams developing on our chain.

In the last 6 months we’ve been listening to the developers and have been working on various new functionalities and features that should help improve the quality and functionality of the projects. Some of them came in the form of development tools which we reviewed last week.

In this article, we will review the new feature sets that are upcoming to help developers improve upon the existing features or add new functionalities.

Some of these features will also create new use cases for the MPC tokens

Improvements in the PBC as a Second Layer Functionality

One of our main value propositions is our cross-chain bridge (Hermes). This unique bridge and gas payment system allows other chains to be a usable asset in Partisia Blockchain. It is this bridge that allows other chains to call our MPC technology as a service and pay for it using their native coins. But at the moment the data that is transferred is through manual data attestation, and the transfer only occurs in one way (PBC -> EVM).

By implementing BYOC messages to be supportable, we will now implement a two way communication system. This allows for the smart contract writer to hook events that are happening in the EVM back to PBC. Through adding a MPC powered threshold key and tying our oracle servers to collateralize these data through MPC tokens, developers will now be able to create an automated bidirectional flow of data between the EVM and PBC. This opens up additional functionality, such as adding message information in NFTs and allowing them to be transferable cross chain, or sending and receiving of data during the actual bridging transfers.

Staking as an Insurance

Currently, once the funds inside a smart contract runs out, the contract gets deleted. We will be creating a new method to allow for SC owners to stake their MPC tokens as insurance to allow for these smart contracts to continue to live on even if the funds run out of the contract. This will allow for both a safety mechanism in the event funds do run out and also introduce another use for MPC tokens.

ZK Contract Lifetime Beyond 28 Days

Currently the data in a ZK contract lasts for 28 days. Going forward, we will introduce a way to allow for this data to be extendable to go past the 28 days through staking MPC tokens and re-funding the smart contract.

ZK Computation in Batches

This feature will allow for multiple ZK computations to be batchable so that you do not have to execute each and every computation one at a time.

Allow ZK Contracts to Control User Data

Currently the developers writing ZK smart contracts do not have flexible control of the Zero Knowledge data. Through this feature, we will allow for developers to have greater control of the type of data and the control of how the data will be used.

We hope that the above will both help improve the speed in which development can be done as well as allow for new features to be implementable by the developers.

As each of the items complete, we will make a separate announcement in our development channels.

Stay updated:

Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube

Roadmap Spotlight #4: Research into Native Bitcoin as BYOC

Roadmap Spotlight #4: Research into Native Bitcoin as BYOC

Bitcoin is what started it all. The coin that began the blockchain industry and even over 14 years after its initial creation, and after so many new coins trying to improve upon the original, it still stands as the king of crypto currency. It is still the main form used as payment in the blockchain industry and others are either built as bringing functionality more than being a currency or is relegated as 2nd place at best.

As mentioned in our interoperability article, the current blockchain L1 ecosystem are basically in a zero sum game. Every chain is trying to be faster, cheaper, more secure and easier to build on. And each blockchain operates by using their own native coin for their transaction fees. And as DeFi came into the picture, DEX’s began looking for options to allow for swapping between chains that were not native to itself. Enter wrapped tokens.

Currently in the DeFi ecosystem, there is only one way to trade BTC. By creating a wrapped version of itself. Whether its wBTC, HBTC or renBTC, etc, it is basically all a similar form of custodying a BTC and minting an IOU type mirror token on the native network. When the smart contract holding the mirror coin is burned, then the locked, or custodied real bitcoin is released. One of the problem in this system is that you must give trust to the custodians. Not only does this go against the trustless-system ethos of public blockchains, if something happens to the custodians (hack, out of business, etc) then your wrapped tokens could be lost or become worthless.

While Partisia Blockchain can implement wrapped bitcoin as BYOC asset easily, this fundamental architecture of wrapped bitcoin tied to a custody goes against the principles of allowing native coins to be used as a form of transaction payment in the blockchain. As mentioned above, from price parity between real and wrapped BTC, to security issues raised by using a custodian (corruption or even worse, a hack in the custody system) there were too many compromises. And so we are taking the road less traveled and working toward finding a solution to allow for native bitcoin to be usable as an asset in the Partisia Blockchain.

This means we are creating a multi-phase program to build this road. The first phase will be a research phase. We’ve already begun this effort and hope to complete it in the next few months. Once the research is complete, we will know the effort needed and then will engage in an architecture and engineering sessions to plan out the work to accomplish this.

This has some major possible benefits. From allowing users to spend native BTC as gas transactions for applications built on the Partisia Blockchain, to creating a native token swap between BTC and another BYOC chain, or even helping to scale transactions in the bitcoin network, implementing native BTC directly in the Partisia Blockchain network will open up new possibilities in the blockchain industry as a whole.

Please be on the lookout for future news of the results of this research.

Stay updated:

Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube

Roadmap Spotlight #3: Arithmetic MPC (REAL) Protocol

Roadmap Spotlight #3: Arithmetic MPC (REAL) Protocol

Currently our MPC protocol (called REAL) computes binary protocols, but we are going to add an arithmetic protocol in the not too distant future. The “binary” or “arithmetic” property of a protocol is not an indication of what is possible, but rather what is efficient.

Every MPC protocol operates on units of some type, and all applications using MPC are built using a very very small set of operations on this type. Some types are better at some applications than others, which motivates supporting protocols that operate on different unit types.

In binary REAL, the “unit type” is a bit; that is, a number that is either 0 or 1. The only operations we can perform on these bits are exclusive or and conjunction (or XOR and AND). All other protocols have to be built using one or more bits, and a combination of XOR and AND operations.

This naturally means that protocols that can be efficiently expressed as a combination of XOR and AND operations, would be efficient in binary REAL. Such operations include comparisons, any kind of bit manipulation, rotations, shifts, and so on.

On the other hand, operations that require a lot of XOR and AND operations, would be in-efficient. For example, additions, subtractions, multiplications and essentially any operation that is “arithmetic” in nature.

In Arithmetic REAL, on the other hand, the “unit type” is a number between 0 and n (for some n) — and the only operations we can perform are addition and multiplication.

Arithmetic REAL therefore performs very well in applications with a lot of arithmetic. That is, a lot of additions, subtractions, multiplications and so on. On the other hand, applications with a lot of non-arithmetic operations are expensive. For example, it is not very easy to compare two numbers, if all you’re allowed to do is add and multiply the two numbers being compared with each other.

Which for What

Binary REAL, being binary (or boolean) in nature, performs well on applications that are, well, binary in nature. This includes applications such as

  • Auctions (because an auction is just a lot of comparisons)
  • Encryption and hashing with certain ciphers, e.g., AES and SHA (because these ciphers involve almost exclusively bit operations)
  • String operations (most string operations are also just bit manipulations of some sort)

Arithmetic REAL, being arithmetic, performs well on arithmetic applications:

  • Machine learning (all ML requires a large degree of linear algebra, which is just a lot of additions and multiplications)
  • Statistics (for the same reason as above)
  • Voting (because voting can be expressed as simply tallying votes, which is just additions)

By enabling arithmetic computations in Partisia Blockchain, we aim to open up new solutions as well as allow for cheaper and easier implementation of existing ones. From health record analysis to private voting in a massive scale, we hope to achieve a much wider acceptance of MPC as a perfect solution to enabling computation while protecting individual users’ privacy.

Be on the lookout for this sometime in the 3rd or 4th quarter of 2023.

Stay updated:

Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube