It is a truth universally acknowledged that a PoNP network aspiring to be known as a good one, must be in want of a good ranking scale. Why is this important?
- Most importantly, to stay fair. Games have rules. When a game fails to enforce its rules, it’s not a good game any more.
- Get the most value out of the network, whatever the actual number of gateways is.
- Stay on course, grow the network, give people an equal chance to make the best of their investment and access to locations.
- Reward earlier joiners more, based on higher risk, higher reward, but provide subsequent joiners with a fair chance to still get a good reward on their investment.
For all these reasons there must be a scale based on how useful a certain gateway is for the network to provide actual coverage, taking into account the advantage that early joiners have by establishing coverage in certain areas.
I believe we need to separate PoNP (Proof of Network Participation) from the scale. PoNP is a blockchain hardened solution to make sure everyone participates, everyone invests, everyone gets rewarded, everyone pays attention. Deriving the scale from PoNP is probably not the best way, given the relatively low number of packets dedicated to PoNP. For any good solution, you need as much data as possible. This is why deriving the scale from all received LoRa traffic should be better and caters to the possibility of ever having “light gateways”, not participating in PoNP as well.
Factors in calculating a ranking scale of a gateway
- When did the gateway start operating in a certain area
- How much total LoRa traffic they receive and what percentage of that is unique
- LoRaWAN is not the enemy of duplicates (traffic received by multiple gateways). There must be some level of redundancy in the network, it’s a positive, but too much redundancy is a negative (wasted resources)
In response to the above requirement, here’s the proposed initial ranking solution
- Process all traffic received by all gateways
- Find unique communication and see how many and which gateways received it
- Have a list of gateways with data on when they joined (and later, when they relocated)
- Look at each packet of unique communication and assign 1 point to the one that established coverage in the area first.
- Find the second one and assign half a point
- Find the third and assign 1/3 of a point
- This much redundancy should be enough, so don’t assign points to any consecutive receivers
- Calculate a percentage of total points assigned over total packets received. This gives a percentage of how much the gateway is contributing to actual coverage and derive the ranking scale based on this percentage
- No hexagons, no location-only based ranking scale. A gateway in a certain area covered by other gateways but receiving traffic from a direction that is blocked for the other gateways in that area should still be a very useful participant
- Ranking should be based on the accumulated sum of each piece of traffic. Radio communication is chaotic, in a sense, that it can bounce and reflect and everything else. You need the total of statistics to establish any kind of usefulness scale. Location, hexagons, restricting to PoNP packets just won’t come close to being sufficient.
It must be said that nobody expects this to be done and solved at the first attempt. It will be a cat and mouse game and the point of our effort now is to give the cat as much of a head start as possible. New and more sophisticated ways of gaming the network will always emerge but the overall impact must be kept at a minimum at all times. Starting unprepared would just leave the cat one or several steps behind.
Let’s take some examples of trying to game the network and how this scale would be preventative of the attempt
- Establishing a farm of many devices in a warehouse and either giving them the same split antenna or just leaving them with a small antenna receiving traffic from the enclosed area itself. This should, in any case, result in many duplicates received and thereby would mostly count as one single device.
- Declaring that the device is somewhere else. Since the location is not an immediate factor in the scale, this should not be a major factor. When it comes to moving your device to a new location where others have already established themselves and potentially causing a negative effect on their earnings, it should be easily detectable when your usual witnesses have changed completely. This should cause a reset of the seniority rank of the device having moved.
- Duplicating a device with the same unique id. This should be a no gain independent of the rank scale. Getting on the blockchain uses a 2 factor authentication evaluated on the blockchain itself. You cannot get the same unique id created on the blockchain twice. Operating 2 devices with the same unique id and wallet will not be able to make more in send rewards, should be quite easily detectable as duplicate attempts to send when directed, and receiving traffic from seemingly separate locations should also raise flags.
- Changing the unique id. This should cause the device to be not operable, or at least not capable of receiving any rewards, given the fact that creating a new wallet for it on the blockchain would require the unique id to be loaded on the blockchain first and a password provided to the owner for onboarding. Blockchain based takeover passwords in Crankk onboarding are one-time only and get deleted in the event the process concluded.
- Stolen device. Changing a wallet assigned to an existing unique id requires a one-time password to be re-assigned to a new wallet.
- Channeling LoRa traffic from somewhere else. This, I believe, requires more sophistication. The traffic would still need to be unique and believable. If someone is selling their traffic to be used in Crankk then this would only be unique once and any subsequent ones would be seen as cloned and gaining no value. Selling it to one customer is probably a lot less lucrative than being able to sell it to many.
- Generating traffic. Well, this requires the most sophistication and we’ll need to see what people come up with to say something about catching these. One thing to be said is that existence of a certain kind of traffic is as telling as the lack thereof. If a miner insists that this is the kind of traffic they are getting then at least some of it should be received by one or more of their witnesses as well.
For code afficionados, here’s a snippet of the ranking code in javascript
setInterval(async ()=>{
if (t.nodes.size === 0) return
this.buffer = this.buffer.filter(e => e.ts > Date.now() - 1000)
const unique = [...new Set(this.buffer.map(item => item.eui))];
for (let i in unique) {
const items = this.buffer.filter(e => e.eui === unique[i])
for (let i in items) {
items[i].nth = t.nodes.get(items[i].gwId)
}
const sorted = items.sort((a,b) => (a.nth - b.nth))
const award = sorted.slice(0, 3)
for (let i in award) {
const gwId = award[i].gwId
const awd = Math.floor(1000 / (parseInt(i)+1)) / 1000
// console.log(i, gwId, awd)
this.rank.set(gwId, this.rank.get(gwId) + awd || awd)
}
}
}, 1000);
Closing words for now
All above is an attempt to solicit feedback and opinions. Even though a scale can be calculated this way, for now it doesn’t have an impact on rewards calculation. My plan would be to start using it (or the improved version based on feedback) in the near future to cause a 10% variation in rewards. Then as more feedback and more finetuning is achieved, increase the impact to 20%, and so on.
Let me know what you think as a comment here or on our Discord.
