At present, it requires a fair amount of technology knowledge to build and support a node in PBC. While many who do not have a technology background have been able to build and maintain nodes, it still creates a barrier that many individuals or organizations feel hesitant to cross. The other challenge is the current staking and job association process. Because the staked MPC tokens in a node are being used as collateral for all the types of jobs the node is running, unstaking and unassociating tokens that are being used can be a challenge.
This is why we are putting focus on implementing a simpler node setup and operations process. This will allow easier setup of nodes as well as easier associating and dissociating of your tokens.
These new features will be rolled out in phases, with the first one being automatic node registration. A simplified registration process will be rolled out where just the configs on your node will kickstart the KYC/KYB and the registration process.
Second phase of the project will be to simplify the association and dissociation of your staked tokens. It will all be a part of our “Staking 2.0” model, which will look to make it easier and less restrictive for both node operators and delegated stakers to manage their stakes.
Running a node will still require some level of technical skill. We hope by automating some of the process, it will make it less confusing and easier for the registration process.
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube
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.
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube
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.
Website • Twitter • Discord • Telegram • LinkedIn • Facebook • Instagram • GitLab • Medium • YouTube