Introducing Testnet Stage 0 Updates

Dear community,

Stage 0 of our Testnet is live, and we are more than happy with how the testing process is going. So far:

• 136 addresses have received miner rewards.
• 4223 batches have been added to the Bus tree (numBatchesInBusTree).
• 67862 UTXOs were processed in these batches (numUtxosInBusTree).

(Ongoing data from  https://mumbai.polygonscan.com/address/0x678D34aA4fc546bA806287a8289FfdAA84681a03#readProxyContract)

Other preliminary results from this testing phase tell us that:

• The iteration algorithm (one-run Miner client usage with a cold start) works as expected.
• We have validated the number of miners needed to support the protocol at a projected (optimistic) capacity. According to data, 5-10 permanently-online miners are enough resources to support the protocol’s users.
• Possible optimization areas are available and will be addressed.

Both regular end-users and a tech-savvy group of profoundly involved community members have engaged with this stage. The latter has gone above and beyond,  interacting with the docker image and even updating it to circumvent some limitations (well done!)  

The past few days of Stage 0 testing generated as much data as the protocol is expected to generate during a few weeks with our projected workload.

Now that our target is achieved in terms of data flow, we are switching to mining reward mechanics and sets of parameters that aim to optimize how rewards are distributed and queues are mined.

Links and details of the new version

The new version aims to address a bug in which the in-browser Miner client isn’t able to iterate through batches, fetching them from a graph.

The smart contracts were also updated to limit the mining of semi-empty queues. To limit semi-empty queue mining, this commit introduces a requirement of "maturity" for queues:

• A partially populated queue must remain pending processing for a number of blocks, which declines linearly with the number of UTXOs in the queue (fully populated queues are processable immediately).
• The above number of blocks (every block on Mumbai is ~2 sec) that a partially populated queue is disabled for mining, counted from the block when the 1st UTXO was added to the queue, is now computed as follows (rounded down):
  

N = 100 * (64 - number_of_UTXOs) / 64

Note that “100” above is an adjustable parameter that might be tweaked further.

You can find the updated versions of the following:

• The browser-based Panther Miner Client at: https://ipfs.io/ipfs/Qmae7K54pW8uzHZcnisym6F5gTrcjQDci8w5Z4XKyDQ7Tk (This option is no longer available).
• The docker image via the existing link at: https://hub.docker.com/r/pantherprotocol/miner-client.

Note that:

• Only ~20 new queues per hour are available for mining. This and other parameters influencing rewards may be tweaked this week as a part of the test program.
• The new Miner will have significantly higher chances of mining a queue than the previous one.

Digging into the Panther Miner

The current code of the Miner aims to test features (SDK) that will support two particular cases in Panther's v1:

1. To mine a particular queue (for which the user is a pending UTXO owner) when miners are unavailable as a service for whatever reason. Once Panther’s v1 is released, you will be able to mine the queue containing your UTXO yourself.

2. To run in-browser while the user has the dApp open (for a short time relative to a dedicated node Miner). This will be optional and triggered by the users themselves.

It should be noted that the current Miner implementation is not about continuous usage and supporting a high load; its goal is to test iterative flows and non-standard/less expected use cases (e.g., miners not being available).

At a later stage, the next version of the Miner client will be released to satisfy the protocol mining needs at a multi-network stage. Besides the existing features, this version, known as the Panther Node, will also support data indexing and inter-chain transactions, running for a long time without the need for restarts.

It’s been great to see your support for this first Testnet phase. Keep going, keep testing –and thank you, Panthers!

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.

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

Share this article on: