Hello fellow followers! I am sure you all noticed we are for the first time a little behind on our schedule, so we thought we should have a status update.
As you already know, we were scheduled to launch on the mainnet during October. Regardless of several EOSIO delays (for example in our initial planning we expected EOSIO 1.8 months earlier and hopping for 2.0 with the EOSVM at this time), we are ready for mainnet, finishing off security audits. We made this announcement and then… as you know… all hell broke loose. Immediately after the announcement, the EOS mainnet entered congestion mode, making our test deployments much more troublesome that necessary and expected. Thankfully with REX it becomes easier, but still, things became much more expensive and slow to test.
This made it obvious to us that eventually, we will have to start pushing one of our alternative implementations of the pEOS technology. One that requires some changes into the EOSIO system itself. We initially didn’t push for those as it would require Block.one to implement/approve these, and it would make it very unpredictable to estimate and plan for. Instead we pulled every rabbit from our sleeves and used every trick in the book of code optimization to make pEOS possible without any native cryptography support. So after witnessing the quick growth of the network and the future need for further optimization, in parallel to the launch and to lay the ground for this, we posted our first EOS Improvement Proposal: https://medium.com/@pEOS_one/eos-improvement-proposal-8148480043b6 after Dan Larimer’s suggestion.
What would change with the above proposal, I hear you ask. Well, pEOS transactions will become orders of magnitude more efficient on CPU usage. This was not a problem on a normally operating EOSIO network, but right now it’s a necessity. We made attempts to adapt to the situation by capping the ring sizes for launch, and after 1.8 to maybe have us (the pEOS team) take up the CPU costs for the users. We quickly adapted the system to do it this way so we can launch with a usable pEOS system, but then the situation revealed itself at its full glory…
Right now, for example, it would take approximately 170 EOS staked to run a single pEOS transaction! And then you can’t run a second one for 3 days. Of course, there is REX that was a kind of solution, but the last days even that runs out… quick sand… So even with the team paying for the cost there is now not enough REX!!! It’s evident that we need permanent solutions and not to keep playing hide and seek with every problem EOSIO throws at us. Native cryptography operations as described in the proposal will allow for orders of magnitude less CPU needed, and bigger ring sizes that make the system more secure.
Therefore now the implementation of the improvement proposal is of paramount importance. The delays in EOSIO improvements (mostly in adoption), along with the ever-accelerating EOSIO usage, made it so that it’s now mandatory to have these cryptographic operations in the core in order to have a functional and usable system.
I call everyone to be patient and allow all the dapps that are facing similar problems to find solutions to rectify the situation. Every single project on EOS contacted us about using the pEOS technology, and we know first hand the deep need for what pEOS is bringing to the table. Therefore we know most dapps are struggling right now. The pEOS team is not giving up. We stick to our plan and try to solve this too. Please do your part and push for the inclusion of our improvement proposal, because congestion is not going away for the long term.
p.s. At the time of writing this, the pEOS contracts work fine providing utxo transfers (using the resources we managed to get before the depletion of REX) and the wallet gets some nice usage.
Website: https://peos.one
Telegram: https://t.me/pEOSone
Telegram China: https://t.me/pEOS_china
Twitter: https://twitter.com/peos_one
GitHub: https://github.com/peosdev
