Testnet Stage 0 Is Now Live! Here’s how to participate.

Panther community,

As we announced this Friday, we’re rolling out Panther’s Testnet today, starting with Stage 0: ZK Batching. In this Stage, we’re launching the Panther Miner, a specialized miner designed to interact with a blockchain network.

This testing stage (and activity in production) is directed towards miners, a key role in the Panther ecosystem, as opposed to DeFi users. However, anyone can become a miner and test during Stage 0. As announced previously, Stage 0 will have dedicated rewards for this kind of testers.

Here’s everything you need to know about Stage 0 and how to participate.

Basic concepts

Panther’s Multi-Asset Shielded Pool (MASP) or “Shielded Pool” for brevity, is essentially a collection of append-only Merkle trees. It includes the following trees:

• “Bus” processes UTXOs collectively by batching them (see below).
• “Taxi” processes UTXOs individually and will be tested at Stage 5.
• “Ferry” will manage UTXO data in the multi-chain Panther ecosystem.

Within the “Bus” tree, each leaf is a commitment to:

1. Either an “asset” UTXO representing a number of zAssets (or zNFTs) (essentially an “IOU” for the corresponding underlying collateral locked on the Panther Vault); or
2. a “zAccount” UTXO, a record that keeps information about the owner of a zAccount.

The name ”'Bus Tree'' comes from UTXOs getting on the tree in batches of up to 64 UTXOs at once, rather than individually. To get on the “bus”, a UTXO needs to be put on a queue and wait until a miner (known as “Bus operator”) processes it and the other UTXOs on the queue.

The “bus” approach makes the process cost-efficient as all UTXOs in a queue share processing costs. As such, the individual cost for a transaction per user is much lower. On the other hand, users become dependent on the “Bus operator” who decides which queue to process and when to process it. Just like users of a blockchain incentivize miners to pick up their transactions by defining how much they are willing to pay for “gas”, Panther Protocol users define the reward (denominated in $ZKP) that they are willing to pay to the miner who processes their UTXOs.

Testnet Stage 0 implementation

Within Panther, miners are responsible for running a piece of code that fetches the pending mining queue. They then compute updates to the Merkle trees needed to append the UTXOs of the queue to the trees, create a SNARK-proof that proves the correctness of the updates, and submit these updates to be written on-chain together with the proof to smart contracts. As such, the Panther Miner software acts as the “Bus operator” on behalf of a user.

In this implementation, the algorithm to reward miners is fairly simple. Eventually, the Panther community may want to implement a more sophisticated algorithm after some initial usage statistics are collected.

As mentioned, the user transacting defines the reward per UTXOs he/she puts in the BusQueue. The initial value for Stage 0 is 0.1 ZKP per UTXO.

The total amount of rewards for all UTXOs in a queue (“assigned rewards”) is split in two parts:

• A “guaranteed” reward, set at 80% initially, which the miner who processes the queue gets in any case.
• A “contribution to reserves” used to pay for bonuses (explained below).

Should there be reserves to permit it, in addition to the “guaranteed” reward, the miner who mines a queue may get a premium. Premiums are calculated proportionally to the number of blocks that have passed without the queue getting processed, counting from the creation of the earliest UTXO in the queue. The bonus will be calculated through accrual at a fixed factor, initially set at 0.1% of the “assigned reward” for every pending block.

How to test

To test at this stage, follow the steps below.

Testing on a browser

1. Visit the miner test page at https://ipfs.io/ipfs/Qmae7K54pW8uzHZcnisym6F5gTrcjQDci8w5Z4XKyDQ7Tk
2. Fill in the following three variables:

• Interval (in seconds): the designated pause between iterations produced automatically by the miner. An iteration includes:

1) Checking the BusTree contract for a queue expecting processing and selecting the most profitable one to process.

2) Generating a zk-proof by processing the chosen queue.

3) Submitting the zk-proof to the blockchain.

• Private Key: the private key of the wallet used to sign batch transactions and receive rewards.

There are two options for this field:

1. Use an existing key, e.g., exported from your MetaMask; or
2. Generate a new key pair. Click “Generate private key using MetaMask” and get a new private key inserted into the corresponding field. You can add the new address to your MetaMask (click “Show Private Key” to unveil and copy the data) afterward.

A new public key (address) will be reflected as soon as you start mining. Find it in the “Mining statistics” section.

• RPC URL: use any RPC you prefer, as long as it’s valid for the Mumbai network.

3. Ensure you have a positive balance of MATIC in your wallet to interact with the product. You can visit faucet_1 or faucet_2 to get test MATIC tokens.

4. (Optional) Add the tZKP token to your wallet using the following contract address 0x4004C49aBb96B11D89A52DeCCa2D1522da7f3089 (it is reflected within the “Mining Statistics section”/”Reward” field). You will see your ZKP balance increasing as soon as you start mining queues. Your reward balance is also available on the UI (see below).

5. Click the “Start Mining” button to start the process.

6. Check that the “Logs” section is updating.

7. Check that the “Mining Statistics” section is updating.

Please, note:

• The “Generated Proof” amount can be bigger than “Submitted Proof,” meaning other miners submitted a generated proof earlier than you.
• “Mining Success” = “Submitted Proof”(s).
• Your Balance (of MATIC) will decline over time because the miner client generates UTXOs to let you interact with them to test the functionality. Submitting UTXOs incurs a cost.
• “Reward” ($ZKP balance) will grow over time if your mining activity is successful. Rewards are distributed as soon as data is processed.

8. Check that you’re receiving rewards correctly.

9. Stop mining. (Note: the miner will finish the ongoing iteration before entirely stopping).

Using a docker image

For users interested in running the Panther Miner themselves instead of using a browser version, the dockerized version has the same functionalities and logic outlined above.

Here’s the link to the docker image page: https://hub.docker.com/r/pantherprotocol/miner-client

Smart contract details (on Mumbai)

• BusTree: 0x678D34aA4fc546bA806287a8289FfdAA84681a03
• tZKP Token (test token on Mumbai, replica of Polygon version of ZKP): 0x4004C49aBb96B11D89A52DeCCa2D1522da7f3089
• VPool: 0xCd85e3E918F1A36F939281d3ca707EE262a364c6
• test DAO multisig: 0xfB474a7FeCDaFBD412ebF0d60A0C32794F82d3dD
• PantherVerifier: 0xeeAfce13506847a19141A4513718df17383f4f7b
• PantherPool: 0xfDfD920F2152565E9D7b589e4e9faeE6699AD4bd
• Vault: 0x9619bd59411a8387a4119e548017C5b86c7bCec5
• FXPortalBridge: 0x542c2c3e6BBfD5979E5FEC6708764B93Ba210c51
• Test ZKP Token (replica of ZKP on Ethereum Mainnet for e2e simulation purposes): 0xfD466eF2c700E2f66b2d05D92896b95d541e66e5

My transaction failed. Is that a bug?

If your Miner logs “Mining error: Error: transaction failed,” this likely means that other miners have been luckier than you and already mined your target queue.

Here are some common error messages, how to find them, and their associated causes.

Finding the error message

To view the smart contract error message:

1. Copy the ‘transactionHash’ on your Miner’s Logs report
   (similar to “0x8df373d7f9dd0c89fa42fc769f91a7153a1e983000916677c588b78d88a32f0f”)
2. Open https://mumbai.polygonscan.com/ and paste the copied ‘transactionHash’ to the search filter.
3. Note the “status” field. It contains the smart contract error message.

Error: BT:FAILED_PROOF

If this message shows, check the following:

• Your miner’s failed “onboard queue” transaction follows immediately (or a few seconds) after another transaction.
• A successful “Simulate Add Utxos To Bus Queue” transaction was sent from another address.
• The “queueId” of your miner’s failed transaction (you can find it on the block explorer’s “input data” section for your transaction) is the same as for the preceding transaction (you can find this amongst the parameters of the “UtxoBusQueued” event shown on the “Logs” page for the preceding transaction).

If both of the above are true, this is not a bug. Your Miner tried to mine a queue that was not fully populated. The preceding transaction has added another UTXO to the queue, which your Miner did not account for.

Error: BQ:EMPTY_QUEUE

If this message shows, check the following:

• There is another successful “onboard queue” transaction that precedes your Miner’s failed “onboard queue” transaction.
• Your transaction and another transaction both have the same “queueId” param (you can find it on the block explorer’s “input data” section for a transaction).

If both of the above are true, this is not a bug. Both you and another user were trying to mine the same queue, but they were lucky to mine it before you.

Submitting feedback

If none of the cases above apply to you, please share your found bug with the Panther team. To share feedback, testers will be using a dedicated form as the only accepted procedure. The steps mentioned in the form’s description are needed to make this interaction both efficient and productive.

Disclaimer

For the avoidance of doubt, test $ZKP (tZKP), test PRP (tPRP) and other tokens described in this article are for testing purposes only and have no economic value, nor can they be exchanged for value. Testnet does not provide you with, nor should be used for, any of the following: create, store, transmit or exchange tokenized digital assets with any economic value or purpose; or create, earn or receive any tokenized digital assets that have value or are exchangeable for value. Participation on our incentivized Testnet versions may result in you earning rewards, but for the avoidance of doubt, such credits are not represented on any blockchain as tokens.

About Panther

Panther is a cross-protocol layer that uses zero-knowledge technology to build DeFi solutions that meet regulatory requirements and satisfy users' on-chain data privacy needs. The goal of Panther is to allow seamless access to DeFi and create a cross-chain-supported architecture that serves different use cases. Panther’s zero-knowledge primitives are also generalizable to KYC, selective disclosures between trusted parties, private ID, voting, and data verification services. Starting July 10th, Panther’s Testnet will be available for voluntary testers.

Website · Documentation· Lite Paper · Twitter · Telegram · Discord

Share this article on: