# HIP-15: 信标奖励

{% hint style="success" %}
已通过

本提案建议将覆盖证明（PoC）的验证方式从**多跳**改为**信标**，并改变PoC的**奖励结构**，将见证人奖励和PoC奖励合并，并将大部分奖励给予见证或接收信标的网关。
{% endhint %}

## **概要**

1. **挑战者**：无变化，只要发起挑战就会获得对应的奖励。<br>
2. **被挑战者**：一次挑战的有效见证越多，收获的奖励则越多。当有效见证超过4个的时候，奖励仍会增加，但增量会递减。对于无有效见证的挑战，被挑战者不会收到任何奖励。<br>
3. **见证人**：当一次挑战的有效见证小于等于4个时，每个见证人获得的奖励单位不变；当超过4个时，每个见证人收获的奖励单位递减。

## 目的&#x20;

通过实施信标与修改后的奖励分配体系，Helium网络可以更好地根据覆盖对网关进行奖励。之前使用多跳的PoC方法和奖励结构大量奖励信号发射者，对接收者的奖励却很少。而LoRaWAN的绝大部分应用是用于未经确认的上行链路，这意味着大多数的网关负责接收数据。修改后的奖励结构能更好地奖励真正的网络覆盖者，并鼓励诚实的网关。

多跳PoC比信标要难以实现得多，需要复杂的路径建设和验证，而在长路径中会出现严重的超时现象，导致挑战无法被完成。对于许多LoRa应用来说，更需要更高的传输效率，而对传输的数据大小要求却不那么高。使用信标技术可以降低PoC的实施门槛，这些CPU和链上资源可以重新分配到其他地方。

## 影响&#x20;

因为奖励结构和PoC行为将发生重大变化，所有网关所有者都将受到这个HIP的影响。一般来说，能够见证多个网关的网关可能获得更高的奖励，而只能见证少数网关的网关可能会看到奖励有所下降。

Helium的开发者团队还需要改变区块链核心协议，以改变奖励分配方式和PoC的构建方式。

最后，一些链上参数可能需要更新，以引入新变量，并改变奖励的分配。

## **详细内容**

信标的行为很像单跳的PoC，但没有预定的目标，每个能收到传输的人都是见证者。

信标的发起方式与多跳PoC相同，发出挑战的网关会触发一个另网关发出信标，并收集见证者回执。理论上，每个活跃的网关都会被统一随机选中，所以平均来说每个网关被挑战的次数是一样的。

为了确定单位信标的奖励，我们需要首先定义一个术语--“奖励单位“。一个奖励单位并不是一个确定的HNT数量，而是每个Epoch中PoC奖励的一个比例。因此，举例来说，如果一个Epoch中有1,000个HNT的PoC奖励，但只有100个奖励单位，则每个奖励单位将得到10个HNT。如果一个Epoch中有5000个奖励单位，每个单位将得到0.2HNT。每个Epoch内的见证人的奖励将根据见证人总数而产生变化。

下面的公式和示例图阐述了每个信标的奖励单位是如何计算和分配的。

### 信标奖励公式

**定义**：

* `w`: 见证人数量；
* `N`: 目标网关冗余。区域内的目标网关数量为`N+1`；
* `r`: 当`w>N`时的被挑战者奖励衰减率。

**被挑战者奖励公式：**

![](/files/-Mf1tAXgarcSr83uyAES)

**单个见证人奖励公式：**

![](/files/-Mf1tK1Jc1kBN-xUiSbD)

**当`N=4`，`r=0.8`时的奖励分布情况如下：**

![Reward\_RX：见证人奖励单位；Reward\_TX：被挑战者奖励单位](/files/-MYiHzAj-k2xEOXunudb)

在上面的奖励分布中，共存在3种情况：

`w < N` 相较企业级别的网关，网关可靠性较低，所以我们希望`N`大于1，以保证区域内有多余的射频覆盖。如果见证人（w）的数量少于N，那么这个区域的覆盖程度仍然有待加强。每个见证人奖励单位都为最大值=1，被挑战者（信标发射者）则根据见证人的数量按比例得到一个较小的奖励单位，从而鼓励信标发射者尽可能更频繁、更广泛地进行广播，加大区域内的见证情况。

`w = N` 在此情况下，该区域覆盖的冗余度已经达到理想情况。挑战者与见证者的奖励单位均为1。该信标总共有`N+1`个单位的奖励，每个参与者得到1个单位。

`w > N` 如果见证者的数量大于期望值，则意味着该区域信标发射者的冗余覆盖率太高了。我们仍然希望信标发射者保持较高的活跃度与发射范围，所以改情况下见证人奖励的一小部分（最高为1个额外奖励单位）将被分配给发射者。所有见证者则将分配剩余的奖励单位。这意味着给予所有参与此次信标的网关的总奖励单位仍然是`N+1`，所以过多的见证人的数量将降低单个见证人奖励。这种奖励结构仍然鼓励见证人进行见证，因为即使见证人得到的奖励越来越少，他们仍然会继续得到奖励，所以对于见证人来说，尽可能多地进行见证并无坏处。

总的来说，以上奖励分布应该可以鼓励被挑战者尽可能多地发射信标，同时鼓励见证人尽可能多地接收信标并提供见证。因此，每个都网关有动力提供尽可能多的覆盖，而不为过度覆盖提供过多奖励。这种奖励结构能够更好地提高目标覆盖率，并不带来太多冗余。

注意：当前并未设置最大的见证人数量，今后可以通过加入此变量，来限制每次验证的交易规模与资源消耗。

#### *奖励单位示例*

假设在`N`=4, `r`=0.8的情况下， 被挑战者与见证人可获得的奖励单位如下：

| 见证人数量    | 1    | 2    | 3    | 4    | 5    | 6    | 7    | 8    |
| -------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 见证人奖励单位  | 1.00 | 1.00 | 1.00 | 1.00 | 0.76 | 0.61 | 0.50 | 0.43 |
| 被挑战者奖励单位 | 0.25 | 0.50 | 0.75 | 1.00 | 1.20 | 1.36 | 1.49 | 1.59 |

| 见证人数量    | 9    | 10   | 11   | 12   | 13   | 14   | 15   |
| -------- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 见证人奖励单位  | 0.37 | 0.33 | 0.29 | 0.26 | 0.24 | 0.22 | 0.21 |
| 被挑战者奖励单位 | 1.67 | 1.74 | 1.79 | 1.83 | 1.87 | 1.89 | 1.91 |

### 见证人距离限制&#x20;

要成为见证，需满足最小半径距离`R`（目前约为300米）。只有见证距离超过`R`的见证人才会被计入奖励范围内。

### 见证信号限制

除了不满足最小半径距离而被排除的见证，系统也会通过RSSI、SNR或其他检测方法来发现异常见证，并将其列为无效。 该策略并不能够简单粗暴地执行，因为一个作弊的网关有可能有许多见证人，在大多数都是无效的情况下，但仍有一些 "幸运 "的见证人可以返回有效信号。具体的识别与惩罚机制可以随着信号评估方法而改变，本提案仅描述了一个基于PoC V10的简单方法。

根据这些限制判定的无效见证计入`w`，但不会获得任何奖励。对于被挑战者来说，所获得的奖励单位是以有效见证人的比例来计算的。这**可能**对诚实的网关有轻微的惩罚，因为被挑战者有可能遇到无效见证。不过在正常情况下，一次传输的无效见证百分比应该很低。如果无效见证的比例很高，那么该信号的发送者很可能也是无效的。

#### *PoC奖励示例*

下表列出了在不同见证人数量的情况下的奖励分配：&#x20;

| 情形          | 12 个见证人 | 8 个见证人 | 4 个见证人 | 2 个见证人 |
| ----------- | ------- | ------ | ------ | ------ |
| 距离大于`R`的见证人 | 12      | 8      | 4      | 2      |
| 无效见证        | 0       | 0      | 0      | 0      |
| 单次见证奖励      | 0.26    | 0.43   | 1.00   | 1.00   |
| 被挑战者奖励      | 3.18    | 3.41   | 4.00   | 2.00   |
| 见证人奖励       | 1.83    | 1.59   | 1.00   | 0.50   |
| 总奖励         | 5.00    | 5.00   | 5.00   | 2.50   |

下表列出了在有无效见证人情况下的奖励分配：&#x20;

| 情形          | 12 个见证人      | 12 个见证人     | 4 个见证人     | 4 个见证人     |
| ----------- | ------------ | ----------- | ---------- | ---------- |
| 距离大于`R`的见证人 | 12           | 12          | 4          | 4          |
| 无效见证        | 2            | 10          | 1          | 3          |
| 单次见证奖励      | 0.26         | 0.26        | 1.00       | 1.00       |
| 被挑战者奖励      | 2.65         | 0.53        | 3.00       | 1.00       |
| 奖励系数        | 10/12 (0.83) | 2/12 (0.17) | 3/4 (0.75) | 1/4 (0.25) |
| 见证人奖励       | 1.53         | 0.30        | 0.75       | 0.25       |
| 总奖励         | 4.18         | 0.83        | 3.75       | 1.25       |

### 多跳 vs 信标

下面列出了五个例子，来比较多跳PoC与信标PoC奖励模式下的差别。为了进行规范的比较，这里将把一个完整的挑战（射频接收、p2p接收、射频发射见证）的奖励作为多跳PoC的一个奖励单位，类似于该提案中的信标。

请注意，在多跳系统中，初始网关只能获得2/3（0.67）的奖励单位，因为它不能证明具有接收射频的能力，它只能通过P2P进行接收，不会获得奖励。

![](/files/-Mf6jRSsN_6-e_X-Gmrp)

上图描述了以下6种情况：

1. 图 a：两个孤立的网关，只能互相见证。&#x20;
2. 图 b：成串的五个网关A-E，其间的见证关系是不对称的。B可以见证A，但A不能见证B，C可以见证B，但B不能见证C，等等。
3. 图 c：与（a）类似，但每个位置都有100个网关串联。&#x20;
4. 图 d：一个由24个网关组成的环，这些网关都可以互相见证。（假设网关的间隔超过了见证所需的最小距离）
5. 图 e：六个网关，中心的网关A可以见证所有其他网关的传输，所有其他网关可以也见证A的传输。但网关B C D E F之间不能互相见证，只能与A通信。&#x20;
6. 图 f：一个由五个网关组成的环，所有网关都可以互相见证。&#x20;

#### 多跳vs信标奖励预期

| 图例   | (a)                     | (b)                                               | (c)                             | (d)       | (e)                     | (f)      |
| ---- | ----------------------- | ------------------------------------------------- | ------------------------------- | --------- | ----------------------- | -------- |
| 多跳奖励 | <p>A:1.67<br>B:1.67</p> | <p>A:0.67, B:1.67<br>C:2.67, D:3.67<br>E:2.67</p> | <p>A(ea):1.67<br>B(ea):1.67</p> | each:4.67 | <p>A:5.67<br>B:1.67</p> | A-E:4.67 |
| 信标奖励 | <p>A:1.25<br>B:1.25</p> | <p>A:0.25<br>B-D:1.25<br>E:1.00</p>               | <p>A(ea):5.00<br>B(ea):5.00</p> | each:5.00 | <p>A:6.20<br>B:1.01</p> | A-E:5.00 |

我们可以看到，除了（b）和（c）两种情况外，其他的奖励是十分接近的。

在图（b）中，我们发现不对称的见证可能导致多跳奖励被倾向某些网关。网关D得到的奖励大约是网关B的2.2倍，尽管它们有相同的覆盖范围。这一情况在信标奖励系统下得到了改善。

在图（c）中，信标网关的奖励明显高于那些多跳PoC的网关奖励。这是因为大部分的奖励都分配给了见证人，虽然只有两个不同的定位，因为每次信标都可以拥有足够的见证，见证者往往可以获得全额见证奖励。进一步解决这个问题的最好方法，是根据某种形式的密度来折算信标奖励（例如[HIP-17: ](/helium/hip-ti-an/hip17.md)网关[分布密度](/helium/hip-ti-an/hip17.md)）。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://heliumchina.gitbook.io/helium/hip-ti-an/hip15.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
