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

Roadmap Spotlight #2: Development Tools

Roadmap Spotlight #2: Development Tools

One of the main priorities for any blockchain is adoption. The stronger the base that are developing on the chain, the stronger the chain. And one of the important factors for adoption is the ease of development on a chain. For that purpose, we have been working hard on tools to help developers develop and deploy on our chain.

The below are some of the key frameworks, contracts and libraries that will help developers create amazing applications on our chain which we are planning to release in the next 6 months.

  • DEX contracts — We are creating a template for DEX contracts alongside a factory to help developers create new DEX’s as well as onboard new tokens easily. Along with the BYOC Framework, we think this will help deployment of a DEX to be very simple
  • CLI interface for interacting with smart contracts — Currently we allow interactions to our smart contracts through our UI in dashboard or browser. Through enabling interactions to our SC in a CLI, we will allow for developers to create scripts that can automate interactions to the smart contract they are developing.
  • Test framework — Currently the devs need to manually deploy and manually test individual pieces of their contracts. In the new JUnit testing library, developers will be able to test deployment and actions for their contracts. This will enable Continuous Integration during development of smart contracts, where unit testing and cross contract integration testing can be stepped through and asserted.
  • Gas estimation tool — We will be launching a tool to help developers calculate gas for their smart contracts. As our sharding architecture is unique, we want to create a tool to help developers compute their gas requirements for the application in an easier way.
  • ABI for all governance contracts — We will enable interactions with our governance contracts, with documentation for what each of the contracts do.

With these tools, we hope we will allow development in our chain to be easier, and we will continue to focus on building new tools to help the development community.

Many of these items will launch as they get completed, with a full completion date of around the end of 4th Quarter.

Stay updated:

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