This update will cover PKT technology development progress through November & December 2021.
PKT is an open-source project. All of the PKT blockchain code and the various projects being developed in the PKT ecosystem are managed by contributing community members.
The PKT project has no central company, no investors, and no CEO. The project’s trajectory is guided by a four phase roadmap and an open invitation to developers who see value in building technology for the PKT ecosystem. The various PKT projects in development range from wallet technology, mining optimization, and utility use cases, to tools that improve the functionality and availability of these various technologies.
PKT also has a unique community structure. This is because when contributors build technology for PKT, each project is its own unique self-managed endeavor. In PKT, there are a diversity of projects that work in different ways, some are profit motivated with a commercial underpinning, some projects are for the betterment of the ecosystem and some projects accomplish both. This entrepreneurial angle is dramatically different from most blockchain projects that raise venture capital and have a single centralized company working on the roadmap.
Goodwill open-source projects and commercial technology projects help strengthen the PKT ecosystem and nurture the roadmap. This development update will cover several of these in-progress public support projects, in addition to the roadmap projects.
A notable upcoming milestone is the scheduled 9th decimation on block 1,296,000, estimated to be January 27, 2022. This decimation will reduce the 1 minute block rewards from 1,793.33 PKT/minute to 1,613.997 PKT/minute. The 9th decimation is one of four decimations that will occur in the 2022 calendar year. Collectively, these four decimations will reduce the 60 second block rewards by more than 35% by the end of November 2022.
Along with the ending of 2021, comes the new beginnings of 2022. Everyone now has an eye towards the release of in-progress projects, such as the first mobile wallets, lightning network payment channels, paying for VPN using PKT Cash, and the launch of TokenStrike. There are also new projects that are finding their footing and which will pave the road towards PKT’s bright future. These projects include connecting cjdns to PKT Network, developing smart contract capabilities on PKT, and the expansion of wPKT into multiple new utility use cases, to name a few.
The PKT lightning network daemon (PND) is going to be our ticket to the instant and near zero cost transactions needed to achieve a fluid bandwidth marketplace. However, before we can get there we need to stabilize the code and make it work fluidly.
PKT has the only production quality light wallet based on Neutrino. The Bitcoin lightning network daemon (LND) has optional Neutrino support, but the majority of production usage is with a Bitcoin full node backing each instance. To date, the only light-weight wallet with lightning support is Electrum, which the PKT project is also developing on. Once PLD is fully functioning, PKT will have two unique light-weight lightning network enabled wallets.
The AnodeVPN project has also been in the process of porting over each of the functions used in pktwallet to make them available in pld. The intent is to soon migrate PKT wallets to pld. Once pld is migrated as the primary PKT wallet implementation, we will then begin work on enabling and testing the lightning network features of pld.
Since around 2012, the cjdns build system has been implemented in nodejs with the dependencies included directly in the source tree. Though it is more difficult to package and has drawn its share of criticism, this system has proven fairly robust and has made the development process significantly easier. Libuv, the dependency used for operating system bindings, has historically been built using GYP, a build system in python which was developed and then later abandoned by Google.
In the year 2020, Rust came to be present in the cjdns codebase. The reason for this was primarily because idiomatic Rust has a lower likelihood of memory corruption and control flow hijacking bugs than C. This caused Rust to be required on any machine which would compile cjdns. In addition, the python version used in the GYP build of Libuv was version 2, which has reached the end of it’s life and is becoming increasingly unavailable.
As a result, the logic from the GYP build has been copied into the cjdns nodejs based build and we now compile the c files of libuv as though they were part of cjdns proper. This makes it entirely impossible that we ever upgrade libuv, but that was impossible already because we use a special patch to allow events to be registered in windows, for the purpose of the TAP device.
In the future, we plan to migrate away from Libuv entirely toward a Rust/Tokio based event system. This will make way for faster multi-threaded cjdns and a Rust + C mixed codebase. However, for now, python is no longer needed to compile cjdns.
It has been a significant weakness of the PKT project that the public open-source version of PacketCrypt had ceased to be satisfactory for operating a PKT mining pool. There have been new pools that have tried to mine, but all have failed to compete using the stock mining code. This is further based on the fact that all of the major PKT mining pools have developed their own proprietary versions of PacketCrypt, and they are, obviously, unwilling to share.
Seeing this problem, community member company PKT Pal has stepped in to develop code improvements that make PacketCrypt mining more fair. This code development falls under the goodwill category mentioned in the overview above. Now that the code has been released, new mining pools will have a fighting chance to compete. There is an in depth update at the end of this report that details exactly what has been updated in PacketCrypt from a technical standpoint.
As an early Christmas gift to the PKT mining community, PKT Pal pushed a few improvements to PacketCrypt announcement and block mining code. These were based on identifying and exploiting a “bug” in the PacketCrypt protocol, and use of a poly1305 implementation using AVX2.
PacketCrypt core hashing algorithm is based on the “encryption” and “decryption” of random chunks of data roughly the size of an internet packet. This is by design as it is intended that optimized versions of PacketCrypt will be dual-use, usable also for encryption of cjdns network packets. As each cycle of encryption and decryption takes place, the content to encrypt or decrypt is updated, and in this there is a possibility for some optimization.
Because the content to encrypt/decrypt is *overwritten*, the actual decryption can be skipped when the operation is “decrypt”, because that data will be written over. When the operation is “encrypt” it is still necessary to perform the encipherment in order to compute the poly1305 authenticator code. Allowing miners to skip some of the encryption was clearly not the intent of PacketCrypt, but this is far from what would be considered a security vulnerability of the algorithm. This optimization only improved performance by a few percent, but by making it available to everyone, this helps ensure a more level playing field for all miners
The second update was a change of the implementation of poly1305. The poly1305 algorithm is used to attach a code to encrypted content which can, with the encryption key, be used to verify that the content was not tampered with. PacketCrypt uses libsodium for encryption and authentication, and in the case of poly1305, the default version used in libsodium uses only SSE2 operations rather than the newer and more powerful AVX2. We updated libsodium by adding Floodyberry’s excellent AVX2 implementation from poly1305-opt which has yielded approximately a 20% performance improvement.
All together, these updates have improved announcement miner performance by 19 to 25 percent. Of course, once everybody gets the same improvement, nobody is any better off, but with the possibility of selfish miners hoarding secret improvements to the algorithm, this release of public code helps ensure PKT remains fair to everyone.
With the launch of the Obeah Bridge (odapp.io), PKT Cash mainnet coins can now be swapped from PKT to wPKT and wPKT to PKT on a 1:1 basis. The first use case of wPKT was gaining access to public liquidity markets through PancakeSwap on Binance Smart Chain. This has enabled miners and traders to access global liquidity markets, including farming wPKT liquidity pools. WPKT launch has also made it possible to hold wPKT on desktop and mobile MetaMask wallets. However, the importance of wPKT cannot be overstated in terms of utility opportunities in the PKT ecosystem. WPKT provides the PKT ecosystem access to utility functionality in the world of Ethereum Virtual Machine (EVM), including DeFi, smart contracts, and NFTs.
Currently, Obeah Bridge is developing functionality for additional multi-chain bridging and security features. The Ethereum bridge is complete, but a launch is not imminent due to the outrageous gas fees and high cost for liquidity on Ethereum. Bridging to Polygon (MATIC) has almost completed development, however, a launch date has not been identified yet. Bridging to Solana (SOL) has also been discussed, in particular because of it’s SPL token standard, low gas fees, fast transaction speed, excellent wallet technology, and significant growth as a player in the NFT marketplace with candy machine technology. There is enormous potential to leverage the versatility of wPKT to drive utility in the PKT ecosystem.
AnodeVPN is a VPN application that provides VPN for free and users only pay for how fast they want the connection to be where they use their VPN. The functionality of the app will include access to a VPN marketplace to choose from user-rated VPN services worldwide for free and pay for connection speed using PKT Cash with no vendor-lock. The majority of the focus for AnodeVPN is currently on PKD stabilization. This is a methodical process of bug testing, fixing and retesting. Public testing support is requested from the community. Please provide any bug reports on projects.pkt.cash or on the AnodeVPN Github. All feedback is appreciated. The forthcoming launch of the Anode iOS mobile wallet will ultimately include a software update to launch AnodeVPN functionality. More on the Anode mobile wallet can be found below.
For more background on AnodeVPN, please check out the September/October Development Update.
The TokenStrike project is continuing development with a first milestone delivery expected soon. The development team SFXDX is undertaking code review before delivering the first milestone. The TokenStrike repo is available for public viewing.
TokenStrike is PKT’s token protocol, which is designed to enable near-zero cost token issuance with near-zero gas. The protocol is scalable, similar to ERC-20 for Ethereum, however TokenStrike does not have smart contract technology, initially. TokenStrike use cases include easily tokenizing bandwidth for decentralized bandwidth trading marketplaces (PKT DEX).
For more background on the TokenStrike protocol, please review the September/October Development Update.
The Anode Mobile Wallet is completing front end assembly in January with the React Native team. There have also been several challenging hurdles getting PLD to run on iOS. The development team is making daily progress and the expectation is that an alpha version will launch in January 2022.
The PKT World launched a very well-designed Windows-based desktop wallet that includes a built-in mining functionality. The wallet can be downloaded here. PKT World has been developing a completely rebuilt wallet backend, which is expected to make a much faster wallet experience with much lower resource usage. The PKT World wallet will also soon support both the light-weight use ideal for traders and the heavy use of mining wallets. Additionally, the development of a Mac OS and Mobile (Android and possibly iOS) versions are expected to start very soon. PKT World is hoping to show some prototypes in the coming weeks. Details will be shared widely as they become available.
The top 3 PKT mining pools have all been operating and scaling nicely with miner adoption. There are at least 2 additional pools winning blocks, one of which is Pkteer Pool. There is an expectation that Pkteer Pool will fully launch in early Q1 2022.
As reported in the September/October development report, PKT World and PKT Pool are designed to accept both high work announcements (2048) as well as low work announcements, while Srizbi only accepts low work announcements, which requires much higher bandwidth output on the part of the miner. This means that edge miners who may have bandwidth constraints may need to customize their configuration by putting in PKT World, PKT Pool and the other mining pools like Pkteer, Pktco.in first, and excluding Srizbi. However, if a miner is not bandwidth constrained, Srizbi is winning a higher block percentage and so yields may improve by listing Srizbi first and then listing the additional pools thereafter. Miners that list Srizbi on the 2048 difficulty pools may be banned by Srizbi. If your miner does get banned, reach out to the Srizbi team in the chats. Here is a list of the current mining pools.
The first businesses in the PKT ecosystem are the major mining pools, a few server rental businesses, and PKT Pal, which is selling the first consumer-friendly, plug & play Edge Point that monetizes home or office bandwidth. The PKT Cube has attracted a wide range of non-tech customers from around the world who are intrigued by the device’s whisper quiet operation and ability to monetize the bandwidth they already pay for.
One new feature recently released on the PKT Cube’s PkteerOS is called Bandwidth Scheduling. This feature enables people to schedule what time of day they want the PKT Cube to consume certain levels of bandwidth (high, medium, low, or off), so that bandwidth never goes to waste and so as to not interfere with household or office internet usage. Due to the bandwidth requirements of PacketCrypt mining, this functionality is now available from the PKT Cube mobile dashboard.
What is also particularly intriguing with the PKT Cube and PacketCrypt mining in general, is its relative ease to accumulating PKT Cash cryptocurrency. For many PKT Pal customers, PKT Cash is their first cryptocurrency. And since PKT Cash is easily mined, this reduces the friction of buying cryptocurrency via a centralized exchange or decentralized exchange.
PKT Pal is also developing a Bill Pay feature, which will allow PKT miners to use their PKT Cash to pay utility bills and subscription services. This service will eventually be available to anyone with a PKT Cash wallet. More details will be made available as the service gets closer to launch.
PKT Pal is also moving closer to introducing the PKT Mini, which is a smaller, less powerful CPU mining device that will come preloaded with the PkteerOS, so people can access the software without needing to purchase the more powerful PKT Cube. The PKT Mini is estimated to debut in Q1 2022.
The Network Steward funded NLnet is accepting applications for micro-grants every 1-2 months. Visit the application here, with more details available about the User Operated Internet Fund here. Technology development grants are being provided up to 50,000 EUR for a first project. If you are interested in proposing a project, it is recommended to stop by the PKT Chat server and visit the #network-steward public channel to inquire and ask questions before submitting. These are additional resources about what is on the PKT ecosystem roadmap here.
The specific problem with PacketCrypt was in the construction of what are known as proof-trees. In order for a block miner to mine a PKT block, it must collect announcements into memory and then sort them and build a specialized merkle tree. What’s worse is that announcements are constantly arriving at the block miner and other announcements are constantly becoming no longer useful for mining. So the process of sorting and proof-tree computation must take place every time a new block is discovered.
The old PacketCrypt code performed this work on demand, stopping the mining process and performing a relatively naive scan of available announcements which took dozens of seconds, meaning block miners would often spend more time assembling proof trees than actually mining!
The most obvious update to the code was to pre-compute the proof tree for the next block in advance so that mining would not need to stop when the block was found. Beyond that, the goal was to make the process faster and more efficient.
The improvement of efficiency was based on a few observations:
The logic used in the new PacketCrypt code was to break announcements down into *classes*. A class of announcements is a group of announcements mined at the same time and with the same difficulty. Since announcements in a class are functionally equivalent, there would never be any reason to mine with some, but not all, of the announcements in one class.
Announcement classes are further broken down into announcement *buffers*, which are fixed size spaces for announcements to be stored in memory. While an announcement *buffer* is of fixed size, an announcement *class* contains a variable number of buffers. When an announcement buffer fills up, a new one is added to the class and the announcements in the full one are then sorted and split into groups. The sorting is relatively quick because the announcements themselves are not moved in memory, so what is sorted is instead an index table specific to the annbuf.
Because there are many other threads wanting to add announcements to an announcement class, each thread keeps a spare buffer in thread local storage so that if the buffer it is adding to should fill up, it will be able to quickly add a new one to the class. When a thread uses its spare buffer, it then goes about replacing it by *stealing* a buffer from another announcement class.
Stealing is done by identifying the class of announcements which are least likely to be considered for mining (typically the oldest and lowest effort announcements) and taking a buffer away from that class. Like adding a buffer, stealing is a nearly atomic operation which requires very little time in a mutex.
When it comes time to build the proof tree for mining the next block, the new code selects the set of announcement classes which will be used. This operation is very fast because unlike buffers, classes are relatively few in number. Once the classes to use have been selected, the code uses a map/reduce algorithm over all of the buffers in each class in order to count the total number of announcements of each *group.* Recalling the groups which were established after sorting of the announcements in each buffer, these groups are based on the numeric representation of the announcement hash – the same metric used to sort them. This means the last announcement in group *n* shall come just before the first announcement in group *n+1.*
After the parallel map/reduce operation has established the total number of announcements in each group, the group demarcations can be established in the final index table and the announcement indexes can be copied over in parallel. This parallel copy, like the original addition of announcements to a buffer, relies on atomic fetch_add to update an index value so that each thread can “claim” part of the buffer before writing to it.
After the entries have been copied into the big buffer, each group is sorted one last time. This sort is a single-threaded quicksort but the processor is kept busy by the fact that there are many groups being sorted at the same time. After sorting, the groups are deduplicated, because duplicate announcements are invalid in PacketCrypt. Finally it becomes possible to compute the proof tree.
The proof tree is computed layer-by-layer with each layer broken up into chunks for computation in parallel. Furthermore, each chunk is computed using blake2b_simd::many which is able to perform multiple hashes at the same time using AVX2.
These improvements resulted in a significant reduction in the time it takes to compute the proof tree such that in most observed cases, the tree is complete before the next block arrives and thus there is almost no time spent not mining.
Thank you for reading this update and following the progress of the PKT project. 2022 is set to be the best year yet, with a lot of exciting developments, utility use cases and community growth expected.
Jesse Berger & Caleb James DeLisle
Community Members
Go back to Blog →Share this article with your friends
Updates
On June 27th, 2021, the first permanent cjdns session was established using protocol version 22. Version 22 uses a new encryption handshake protocol based on a modified version of Wireguard,…
Updates
An inside look at the blockchain that pays based on internet bandwidth.