<strong class="be">Greetings community!</strong>
Recently, as you all know, the Phore community overwhelmingly voted to launch our new sharding architecture you all know under the project code name Synapse as a new, independent cryptocurrency. This will allow each project to achieve their full potential with their own identities, avoiding brand confusion.
Synapse has always been considered just a code name. We have put a lot of thought into what the name of the new project and cryptocurrency should be. After considering many alternatives and doing some market research to assess which name would be received the best, we have determined the name we plan to use for the Synapse architecture…
<strong class="be">Introducing Graphene!</strong>
Graphene is a material that is 200 times stronger than steel, and much lighter than other competing materials. It is often used in racing bicycles and a myriad of other applications when there is a need to balance strength, weight, and speed.
We think this fits in very well with our vision for this new architecture. A lightweight and versatile network which is extremely strong and secure.
You’ll learn more about the Graphene brand in the weeks ahead so stay tuned!
<strong class="be">Progress Report</strong>
The Graphene architecture is extremely complex, and we have overcome many technical challenges getting development to this point. Given the nature of cryptocurrency blockchains, it is critical to have the core features and protocols functioning correctly from the beginning. While we cannot foresee every potential issue, we are making every effort to launch with a secure, high quality, high-performance architecture, and we are putting significant effort into avoiding unexpected post-launch issues. We have high development and quality standards in everything we do, and we will always live up to those standards. The end result we are working towards is to deliver an extremely high-quality product that is both fast <strong class="jc cd">and </strong>secure.
Development wise, we’re getting ever closer to the finish line. At the same time, there is still work required to clear the final hurdles. The development team is working hard to give the new protocol the last “push” that it needs.
Recently, one challenge we were faced with was in relation to the Shard Chains. This was a particularly tricky issue, and a plan is now in place and we are hard at work. Essentially, the problem is as follows:
Shard chains require a secure and reliable method to determine who the “proposer” for a block is. Previously, we relied on the last beacon chain finalized block, but this did not require the user to process the block before validating the shard block.
The ideal solution would require perfect accuracy so that no blocks are accepted that <em class="mt">shouldn’t </em>be accepted. Also, the solution would operate independent of time, so that blocks can be accepted into the chain even if the beacon chain is “ahead” of the shard chain.
Though this requires a lot of work, the best solution is to add two additional 32-byte hashes per epoch. These hashes will store a RANDAO (decentralized, immutable random number generator) hash, as well as a merkle root of all active validators. The shard chain will include the latest finalized beacon block and will require that this block is processed at the same time that the shard chain is processing a block. Otherwise, it will wait for the beacon chain.
To summarize, when a shard chain is receiving a block, it will do the following:
- Ensure we’ve processed the referenced beacon block
- Retrieve the RANDAO hash and merkle root of validators
- Verify the merkle branch in the block to ensure that the validator matches
- Shuffle the validators and ensure that the validator who proposed is in the correct position.
This is so that no one can fake a signature or merkle branch while referencing a finalized block. These finalized blocks need to be validated by ⅔ of validators to ensure security and chain integrity.
We are happy to report that the fix for this issue has been implemented, and all indications are that the chain is running smoothly.
While this was going on, we have also been running some stability tests. To do this, we have simulated a number of validator nodes and side chains on a private server. During testing, a bug was uncovered that led to a CPU usage of 100% over time. We managed to fix the bug and were able to run 8 shards, 128 validator nodes on a single server — all while only consuming 5% of CPU power.
These long term tests are critical, and make sure that the community has no issues running a validator node on their local machine.
Currently, work is being done on the shard verification and making sure that shard proposer selection is synced.
<strong class="be">Wallet UI</strong>
Our design team has completed the conceptual wallet UI and <em class="mt">man does it look slick. </em>It includes many of the features that our loyal users use most often, put together in a clean, professional package. A sleek dark mode, “recent transaction” window, wallet balance, and a live price feed are all included on the main screen. Additionally, live network statistics (currently using staking and node activity as placeholders) will also be viewable within the wallet.
A working demo of the wallet will be available later this week!
