Crankk.io — A Proof-of-Network Participation Crypto Network on Kadena

Crankk LoRa Gateway (Close to exact look)

Crankk is a Helium-like crypto network and this is the very beginning. Helium is great or has been great but there’s still a huge backlog of miner orders (in the order of millions I hear) and mining returns are already pretty low. One of those would not be a deal breaker but those together may be. We didn’t start Crankk to be a copycat and it won’t be. We followed our heart to create a truly distributed network of independent nodes that do something useful and enable node operators to make tokens in the process. We didn’t take any code or ideas from Helium. Our main goal is to create a Proof of Network Participation (PoNP) unlike Helium’s Proof of Coverage (PoC) network.

Here are a few key features of Crankk

• It runs on an existing blockchain called Kadena and Crankk is a Token on the Kadena network. More on this choice later.
• The Crankk miner hardware is made up of a Raspberry Pi 4 and a LoRa gateway module. One of the bottlenecks of Helium is the licensed hardware manufacturer model. We’ll start with our own hardware but plan to allow open source hardware when the network starts showing some robustness. That should eliminate some of the concerns.
• Crankk nodes are not blockchain nodes. Kadena is a proven, robust, secure, multichain Proof of Work(PoW) network with many Petahash per second total hash power behind it. This should eliminate many other concerns. There are multiple attributes of Kadena that are very beneficial but again, we’ll come back to those later.
• Crankk is focused on proving coverage. How do you prove coverage, you might ask. Well, we didn’t see any other way but to implement something similar to Helium in terms of witnessed broadcasts. It is impossible to prove that Alice sent something to Bob and they both lied about it or told the truth if there were no witnesses of this communication. Another issue is that they could have communicated on the internet or by any other means so proving that they communicated thru the airwaves again comes down to witnesses. There need to be listeners tuned to the right frequency and radio communication protocol to prove that Alice broadcasted something and it was heard by multiple witnesses. If the majority of the network is honest and listens as agreed then the majority should be able to prove the validity of such claim.
• Another concern is that those who didn’t witness it but claim they did should be blocked from getting rewarded. This problem is similar to a fair exchange cryptography problem and the easiest way to solve it is with a Trusted Third Party(TTP). The TTP acts as the director of a certain communication exchange. It tells the chosen radio node to broadcast something and sign this message and encrypt this message with the TTP’s public key. This way only the TTP will know what the broadcaster transmitted and what the witnesses heard. No node can find out what the actual message was unless they really heard it.
• TTP’s are also selected randomly for each communication exchange so collusion is a lot less likely. This method can be extended to multiple TTP’s per exchange to further eliminate concerns.

We need to talk about LoRaWAN

That is the radio communication protocol that Helium and also Crankk serves up as a service for potential users like utility companies, GPS tracker manufacturers, etc, to provide coverage for. The idea is that if a network provides good coverage for a geographic area then it can be relied on without thinking much about where exactly the service is needed within that area. Coverage for that area is proven by the network. A failure would be if coverage shows as “proven” for the area but somehow radio packets transmitted by smart meters or trackers is not picked up by the network because maybe some nodes successfully lied about providing coverage for that area. The goal of the PoNP network is to prevent this from happening. But there is another consideration to be made about LoRaWAN. As you might imagine LoRaWAN protocol designers didn’t optimize the network to be “distributed”. They optimized it to be centralized. What it means is that although you can operate a LoRaWAN gateway and connect it to a central server of your choice, there is still a central server. The reason for that is that in LoRaWAN the client device needs to be registered with one or more central servers that know the client device’s “secret” to be able to decrypt the actual message. Since there are multiple layers in LoRaWAN, only a central server is supposed to know this key and not participants in other layers. This way an encrypted message travels thru the network but the actual message remains secret until the central server decrypts it and with its own central access control, only the actual intended recipient is able to see it. There are other network management considerations as well that make centralization a seeming necessity. Of course this could probably be mitigated and the system made less centralized but that would take extra effort and that was also probably not a design goal for LoRaWAN. As a conclusion we can say that LoRaWAN is not a really good candidate to build a distributed network out of. But at the same time very useful.

Why build on Kadena?

I think this is the best part. There are so many reasons to build on Kadena. Kadena is a true Layer 1 PoW crypto network with special quirks.

• High thruput (estimated 480k TPM)
• Lisp-like smart contract language called Pact that is intentionally Turing incomplete. Turing incompleteness is a good thing here to avoid problems that Ethereum has.
• Kadena has a relational database behind it. This is a very good thing. Blockchains are replicated databases that agree on a consensus state and keep propagating it. If it’s a database then the logical design choice would be to actually employ one. Most don’t but Kadena does.
• Virtually zero gas fees. More on this later.

Why not have our own blockchain?

Well, you could say things like why reinventing the wheel but that’s not the real reason. It will be enough of an undertaking to build a distributed network for a true, practically working proof of network participation, taking on the responsibility of building a blockchain with it, it just exceeds our ambitions. It still involves solving multiple technical challenges

• Integrating with the blockchain and its smart contracts to provide a good token solution
• Formulating governing smart contracts that check and enforce expected client node behavior including regularity of transmissions, validating true witnesses of these transmissions, awarding proper amount of tokens for validated communication exchanges
• Enhancing Chirpstack, the open source LoRaWAN server solution, to implement LoRa gateway to LoRa gateway ping checks orchestrated by the blockchain
• Arranging Chirpstack components (Gateway Bridge, Network Server, Application Server) in a way that serves both LoRaWAN functionality and PoNP necessity

The gas fee saving conundrum

Kadena is great. I think I’ve said that already. But it’s a replicated database just like any other and following the logic of blockchains the same smart contract function needs to execute on many nodes with varying processing power to arrive at a consensus. In the Kadena Pact smart contract language there are SQL select statements available that would make it really easy to orchestrate coordinated efforts over many network clients. However these are resource intensive operations and can potentially create performance bottlenecks. It’s enough if some nodes slow down for the entire network to slow down. The only way for Kadena and any other blockchain to remain resource checked is the implementation of gas fees. Kadena has virtually zero gas fees for most operations. Select operations are not one of those since recently. This makes it a bit more difficult to orchestrate actions over a large number of nodes but certainly not impossible. The workaround here is to come up with an execution plan outside of the blockchain and have it checked by the blockchain as opposed to letting the blockchain come up with the plan itself.

The following 2 sections have been updated. Please read it here in the original format then review updates https://alviso.medium.com/c220b0542404

Tokenomics

Crankk is a maximized-total-supply token. Total supply is 10M tokens on each Kadena chain. There are 20 Kadena chains, so total supply is 200M. Right now only chain 0 is open and there will be no token sale. A new chain will be opened after every 5,000 active gateway nodes to give new joiners a new opportunity to be among the early adopters. Tokens will be distributed evenly over 20 years. That means 10M / number of days in 20 years. About 1360 tokens get distributed per day. The project will take just 1% of emitted tokens to ensure and finance continued development of the network. As I said, there will be no way to buy the token other than when miners will start exchanging it to other tokens on the Kadena network or later, when the Crankk token may get listed on an exchange. Of course you can send your tokens to any address at any time.

Broadcaster / witness rewards

Every gateway is instructed by the blockchain to send a ping every 4 hours. For the sender to get a reward the ping needs to be sent when instructed and received by at least one witness. Half of the allocated reward goes to the sender and the other half is distributed equally among all valid witnesses of the same ping. The total reward for one such exchange is calculated based on the expected number of pings on the network per day to add up to the total planned token ditribution per day. One minor caveat is that below 100 active gateways per chain the reward for one ping is limited to 1 Crankk Token for the sender and 1 Crankk Token for the witnesses.

Prevent gateway clumping

Gateways clumped together and witnessing one another is detrimental to the coverage they provide. Optimally they are separated by hearing distance or some fraction of it. Looking at how successfully Helium has faired in this regard, there doesn’t seem to be an exact and easy way to do this. Gateways do communicate exact timing, RSSI, SNR values of a reception event along with LoRa specific protocol parameters so there is a basis to compare them. There is also a GPS receiver included with the gateway so that it provides GPS coordinates as well as accurate time. But with all this information and considering that GPS information can be spoofed, although not necessarily trivially, clumping detection is still a probabilistic check and not an exact one. That being said, initially, Crankk will not penalize clumping. There will be clear communication with exact time given when the network will start to assign lower awards to clumped gateway nodes. At that time we’ll communicate best practices to maximize awards as well. Until then the only advice is that you place your gateway nodes within hearing distance to one another to make sure you’re awarded.

Consensus group nodes

It is primarily the necessity of a Trusted Third Party(TTP) that the witness validation code cannot be implemented on the blockchain. It could but you always have to assume that data on the blockchain is essentially public. It does not mean that it takes zero effort to get to it but it is definitely possible. That means that the blockchain cannot assume the role of a TTP. The point of a TTP is that it can receive privileged information signed by the sender and encrypted with the TTP’s public key. This eliminates the possibility of nodes that didn’t hear the ping lying about it and saying that they did. Also, the TTP can perform the check and comparison of all radio reception parameters and validate those. This system allows for multiple TTP’s per radio exchange. This greatly reduces the chance of a consensus node colluding with witnesses. How do you become a consensus node? Wallets with highest balances will be automatically admitted over time as needed. There’s a bit more to symmetric and asymmetric key cryptography as well as message signing being used here but we’ll come back to explain more details about this later.

Gas fees paid in Kadena

Since we take advantage of the Kadena Network to operate on we need to pay gas fees in the network’s native token, Kadena. It makes sense to minimize those gas fees. We’ve built our solution to always let the network calculate the minimum gas fee before sending our request thereby guaranteeing that we pay the minimum acceptable fee for our operations. Furthermore we optimized our Smart Contracts to use Kadena as a key/value database to minimize the required minimum fee. Since as a Crankk Network participant you’ll need some minimal Kadena balance we’ll include a complimetary balance of Kadena with every gateway purchase that should last you a long time to cover gas fees.

“Mining” hardware

The “mining” hardware is actually just a Raspberry Pi with a LoRa radio module. It should consume energy similar to a Wi-Fi router so you won’t need to budget for extra operating costs / energy usage. The miner will come in an indoor enclosure with a basic antenna. It will be up to you to potentially get a larger antenna. Our long term goal is to democratize access to both hardware and software and in that regard we are working toward letting everyone build their own hardware and self-install software after we’ve proved the viability and robustness of the network.

Miner buying options / “Hosted” miner

If you check our homepage you’ll notice that there are 2 buying options for now. One is to buy 2 miners and we’ll ship them to you in 2–3 weeks or you can buy a single “hosted” miner that you also own the same way as if we’d have shipped it to you but we’ll host it for you until you decide to take over custody. At which point we’ll ship it to you for a nominal shipping fee. You’ll still operate your own “wallet” which is actually the software for the miner. You can opt to use our bundled cloud service for this purpose or run it yourself as a Docker image . This way the “Miner” and the “Wallet” are separated and potentially make it easyer for you to get started. For now we only have the US LoRa version that can only be legally used in the US. We’ll initially only be able to ship to the US but nothing prevents you from buying a US hosted version from outside the US. The reason we offer the shipped version with minimum order quantity of 2 is that we want you to start earning tokens right away. Before the network grows it is unlikely that your Crankk gateway would find other Crankk gateways to communicate with and then we have no way to prove coverage. We wouldn’t want to make concessions to come up with ways to reward a single isolated gateway in which case there’s no real way to prove coverage. We hope that this way of mitigating teething pains would make sense to you as well.

This is becoming a little long, so let’s wrap up for now and continue in a next post.