IV. SYSTEM IMPLEMENTATION
We adopt modular design following the integration of blockchain. It brings more flexibility by separating the implementation of different functionalities, so we could leverage the advantages of the blockchain-based smart contract while reducing overhead. Figure 3 illustrates how different modules are involved in the interaction between DiFi and users.
我们采用区块链整合后的模块化设计。 它通过分离不同功能的实现带来了更大的灵活性，因此我们可以利用基于区块链的智能合约的优势，同时减少开销。 图 3 说明了不同模块如何参与 DiFi 与用户之间的交互。
A. Overview
Modules belong to the three layers illustrated in Figure 1. Meanwhile, they are divided into “on-chain” and “off-chain” modules, depending on whether they are implemented in or out of the smart contract. Figure 3 shows that DiFi takes “input” from users such as user requirements and payments for Wi-Fi access. Users desire to trust DiFi for processing the “input”. In other words, DiFi has to show that the go-as-you-pay design could be achieved, which is feasible by leveraging the smart contract. Modules of the layer that contains allocation and pricing mechanisms are therefore implemented as functions in the smart contract and are referred to as on-chain modules.
模块属于图 1 所示的三层。同时，它们根据是在智能合约内部还是外部实现，分为“链上”和“链下”模块。 图 3 显示 DiFi 从用户那里获取“输入”，例如用户需求和 Wi-Fi 访问费用。 用户希望信任 DiFi 来处理“输入”。 换句话说，**DiFi 必须证明可以实现按需付费的设计，**这通过利用智能合约是可行的。 因此，包含分配和定价机制的层模块在智能合约中作为函数实现，被称为链上模块。
After processing the “input”, DiFi sends “output” to users. That is, users will be allocated certain quantities of resources, and may also receive suggestion from the feedback mechanism via the user interface. Modules of the layers containing scheduling and feedback mechanisms and user interface are referred to as off-chain modules. We do not implement these modules as part of the smart contract due to its own limitations. Figure 3 also shows the data sharing between on-chain and off-chain modules. Allocation results and prices are computedby the smart contract and stored on blockchain and off-chain modules retrieve them at certain frequency, e.g., per second.
处理完“输入”后，DiFi 将“输出”发送给用户。 即，用户将被分配一定数量的资源，并且还可以通过用户界面从反馈机制接收建议。 包含调度和反馈机制以及用户界面的层的模块被称为链下模块。 由于其自身的限制，我们不会将这些模块作为智能合约的一部分来实现。 图 3 还显示了链上和链下模块之间的数据共享。 分配结果和价格由智能合约计算并存储在区块链上，链下模块以特定频率（例如每秒）检索它们。
The first implementation challenge related to blockchain is to reduce overhead. It may take up to several minutes to process a user request if we deploy our smart contract on the public Ethereum network, due to its proof-of-work consensus mechanism [26] that requires participating nodes to perform computation tasks. Instead, we set up a private Ethereum network with nodes not connected to the main network [27]. The alternative proof-of-authority mechanism significantly reduces the delay of operations. Secondly, efficient communication between on-chain and off-chain components is necessary. Owing to our modular design, we rely on the web3.js libraries [28] to interact with the smart contract, e.g., to call functions outside the smart contract and receive the output results.
与区块链相关的第一个实施挑战是减少开销。 如果我们在公共以太坊网络上部署我们的智能合约，可能需要几分钟来处理用户请求，因为它的工作量证明共识机制 [26] 需要参与节点执行计算任务。 相反，我们建立了一个私有以太坊网络，其节点未连接到主网络 [27]。 替代的权威证明机制显着减少了操作的延迟。 其次，链上和链下组件之间的有效通信是必要的。 由于我们的模块化设计，我们依靠 web3.js 库 [28] 与智能合约进行交互，例如，调用智能合约之外的函数并接收输出结果。
B. Allocation and Pricing Mechanisms
1）Time-slot-based Demand Submission: DiFi’s go-as-youpay design allows users to freely indicate their requirements, however user experience may deteriorate if requirements are always immediately processed. Allocation results and prices dynamically change under varying demand of any user. Users may be less satisfied if such changes frequently occur. Consequently, DiFi processes user demand based on time slots. It allows to set the length of each slot, e.g., 30 seconds, and only processes demand submitted within each slot at its end. Within each slot, users with submitted but not processed demand will receive the basic level connection. They will experience low connection quality, e.g., 512 Kbps of bandwidth and 50 KB of data burst, which is free of charge. The length should be carefully selected to avoid overly long waiting times for new users. Moreover, users may desire to be aware of possible changes in allocation and prices to react promptly, hence DiFi sends optional alerts to notify users.
1）基于时间段的需求提交：DiFi的按需付费设计允许用户自由表达需求，但如果总是立即处理需求，用户体验可能会变差。分配结果和价格会随着任何用户的不同需求而动态变化。如果此类更改频繁发生，用户可能会不太满意。因此，DiFi 基于时隙处理用户需求。它允许设置每个 slot 的长度，例如 30 秒，并且只处理在每个 slot 结束时提交的需求。在每个槽位内，已提交但未处理需求的用户将获得基础连接。他们将体验到低连接质量，例如，512 Kbps 的带宽和 50 KB 的数据突发，这是免费的。应仔细选择长度，以避免新用户的等待时间过长。此外，用户可能希望了解分配和价格可能发生的变化以迅速做出反应，因此 DiFi 会发送可选警报以通知用户。
2）Allocation Computation: One crucial component of the go-as-you-pay design is the allocation mechanism that determines the allocated bandwidth bi and data burst vi for each user i. Apart from the per-user allocation, users would also desire the allocation to be fair, e.g., the ratio bi/Bi shall be identical for any standard user i. Owners would expect the allocation mechanism to be work-conserving. It should also be simple and efficient to be implemented in a smart contract.
Our mechanism addresses the above concerns. Firstly, it is fair among standard users. Our novel design of the guaranteed mode implicitly divides the total bandwidth B into two segments.
is dedicated to the set of guaranteed users J. Each user j ∈J receives bj = Bj
as long as BJ < B. Standard users share the remaining bandwidth in a proportional manner, with user i receiving bi that is proportional to her demand Bi and does not exceed Bi. The ratio bi/Bi equals
, i.e., the supplydemand ratio for standard users. If the bandwidth cannot even fulfill the demand of guaranteed users, DiFi will temporarily disable the guaranteed mode, and all users will receive bandwidth proportional to their demand. Secondly, the mechanism ensures that the bandwidth could be fully allocated; together with the feedback mechanism (Section IV-C3) that attempts to redistribute idle bandwidth, it is almost work-conserving. Lastly, it is also simple and efficient. Our test shows that the typical response time between submitting demand and completing allocation computation is within 0.5s.
Ideally, any user i can always be assigned data burst vi = Vi under our scheduling mechanism (in Section IV-C2). However, we still allocate data burst vi in accordance with the unit price pV , such that the usage fee of data burst remains fixed as long as user i desires the same Vi. Otherwise, we cannot guarantee that the threshold ti is the upper bound of total fee per unit time. A similar design also exists in the allocation and pricing of bandwidth, which will be discussed in price updating.
2）分配计算：按需付费设计的一个关键组成部分是分配机制，它决定了每个用户 i 的分配带宽 bi 和数据突发 vi。 除了每个用户的分配，用户还希望分配是公平的，例如，对于任何标准用户 i，bi/Bi 的比率应该是相同的。 业主希望分配机制能够节省工作量。 在智能合约中实施也应该简单有效。
我们的机制解决了上述问题。首先，在标准用户之间是公平的。我们对保证模式的新颖设计隐含地将总带宽 B 分为两部分。
专用于保证用户 J 的集合。每个用户 j ∈J 收到 bj = Bj
只要 BJ < B。标准用户按比例共享剩余带宽，用户 i 收到的 bi 与她的需求 Bi 成正比且不超过 Bi。 bi/Bi 的比率等于
，即标准用户的供需比。如果带宽甚至无法满足保证用户的需求，DiFi 将暂时禁用保证模式，所有用户将获得与其需求成正比的带宽。其次，该机制保证了带宽可以被充分分配；连同尝试重新分配空闲带宽的反馈机制（第 IV-C3 节），它几乎是工作守恒的。最后，它也简单高效。我们的测试表明，从提交需求到完成分配计算的典型响应时间在 0.5 秒以内。
理想情况下，在我们的调度机制下（在第 IV-C2 节中），任何用户 i 总是可以被分配数据突发 vi = Vi。 但是，我们仍然按照单价 pV 分配数据突发 vi，这样只要用户 i 需要相同的 Vi，数据突发的使用费就保持不变。 否则，我们不能保证阈值 ti 是单位时间总费用的上限。 在带宽的分配和定价中也存在类似的设计，将在价格更新中讨论。
3）Price Updating: Another crucial component of the go-as- you-pay design is the dynamic pricing. DiFi updates the unit prices upon any demand change and calculates an estimated usage fee for reference based on prices.
The first desirable property of the unit price of bandwidth pB is that the usage fee per unit time should not exceed the threshold ti. We adopt a straightforward solution that the usage fee remains the same when the demand of a standard user Bi is unchanged, even if pB varies due to change in the demand of other users. Such design is intuitive for users. Secondly, pB increases with demand and vice versa, hence we allow the owner to set a reserve price p0 B > 0 that represents its lower bound. If the aggregate demand is already below the available bandwidth, the owner may not want to further reduce the price for its revenue. Lastly, we also expect that the unit price of data burst pV grows with aggregate demand. If multiple users have requested large data burst, they are likely to consume data with no speed limit at the same time. The connection would easily become congested just as if there is no bandwidth regulation. To avoid severe congestion, the price pV should increase to suppress demand. Moreover, user i should have less incentive to demand large Vi if the aggregate demand is already high.
We design a pricing scheme to cater to the above expectations. pB is always equivalent to
, where Bi/bi ≥ 1 is the demand-supply ratio for standard users. pB grows with user demand, and each user is charged the same price pB for unit allocated bandwidth. A standard user i pays pB bi = p0B Bi, while a guaranteed user j has to pay a higher pB Bj . Only guaranteed users have to pay more if pB grows. pV is a convex function increasing with user demand, i.e., it grows faster as total demand is higher, thus users have less incentive to request large volumes of data burst.
3）价格更新：按需付费设计的另一个重要组成部分是动态定价。 DiFi 会根据任何需求变化更新单价，并根据价格计算估计的使用费以供参考。
带宽单价pB的第一个理想特性是每单位时间的使用费不应超过阈值ti。我们采用一种直截了当的解决方案，即在标准用户 Bi 的需求不变的情况下，即使 pB 由于其他用户的需求变化而发生变化，使用费也保持不变。这样的设计对用户来说是直观的。其次，pB 随需求增加，反之亦然，因此我们允许所有者设置代表其下限的底价 p0 B > 0。如果总需求已经低于可用带宽，则所有者可能不想进一步降低其收入的价格。最后，我们还预计数据突发 pV 的单价会随着总需求的增长而增长。如果多个用户请求大数据突发，他们很可能同时消费没有速度限制的数据。就像没有带宽规定一样，连接很容易变得拥塞。为了避免严重的拥堵，价格 pV 应该增加以抑制需求。此外，如果总需求已经很高，用户 i 应该没有动力去要求大的 Vi。
我们设计了一个定价方案来满足上述期望。 pB 总是等价于
，其中 Bi/bi ≥ 1 是标准用户。 pB 随着用户需求的增长而增长，每个用户为单位分配的带宽按相同的价格 pB 收费。标准用户 i 支付 pB bi = p0B Bi，而保证用户 j 必须支付更高的 pB Bj 。如果 pB 增长，只有保证用户必须支付更多费用。 pV 是一个随着用户需求而增加的凸函数，即随着总需求的增加它增长得更快，因此用户请求大量数据突发的动机更少。
4）Payment Processing: Users pay the usage fees with the balances in DiFi, which is added by making a transfer to the smart contract and is automatically deducted. The latest results and prices are retrieved from allocation computation and price updating for calculation of usage fees. Each user will be charged the unit prices for unit allocated bandwidth and data burst per unit time. The payment may be in various forms, including a cryptocurrency and a fiat currency. We primarily implement support for cryptocurrency, as it is directly related to the blockchain. If a user wishes to terminate connection, the remaining balance can be withdrawn and transferred back
4）支付处理：用户使用DiFi中的余额支付使用费，通过向智能合约转账的方式添加并自动扣除。 从分配计算和价格更新中检索最新结果和价格以计算使用费。 每个用户将被收取单位分配带宽和每单位时间数据突发的单位价格。 付款可以采用多种形式，包括加密货币和法定货币。 我们主要实现对加密货币的支持，因为它与区块链直接相关。 如果用户希望终止连接，可以提取余额并转回
5）Account Management: DiFi requires user accounts to associate users with information such as balances. We leverage the blockchain accounts [29] to simplify the implementation as well as avoid potential security flaws. Each user accesses DiFi with a unique address, e.g., 0xb5f8295c: : :. Similar to the web UI of existing systems, a user will be redirected to the account page upon getting connected to the Wi-Fi network. In addition, DiFi allows users to create a temporary account on the blockchain, to provide better privacy and security.
5）账户管理：DiFi 要求用户账户将用户与余额等信息关联起来。 我们利用区块链账户 [29] 来简化实施并避免潜在的安全漏洞。 每个用户使用唯一的地址访问 DiFi，例如 0xb5f8295c: : :。 与现有系统的 Web UI 类似，用户在连接到 Wi-Fi 网络后将被重定向到帐户页面。 此外，DiFi 允许用户在区块链上创建一个临时账户，以提供更好的隐私和安全性。
C. Scheduling and Feedback Mechanisms
1）Transparent Proxy (Session Splitting): To achieve userlevel control of bandwidth and data burst, DiFi has to split the connection sessions of different users before scheduling the data transmission. Yang et al. [30] introduced a “transparent proxy” design. It achieves packet-level centralized control at the ingress/egress point into the Wi-Fi network. We leverage the design since it relies on transparent modifications and requires no change to the existing infrastructure. The transparent proxy determines whether a packet is being sent to or from a specific user by extracting the source and destination IP addresses, and passes the results to the scheduling mechanism.
1）透明代理（Session Splitting）：为了实现用户级别的带宽和数据突发控制，DiFi必须在调度数据传输之前将不同用户的连接会话进行拆分。 杨等人。 [30] 引入了“透明代理”设计。 它在 Wi-Fi 网络的入口/出口点实现数据包级集中控制。 我们利用该设计，因为它依赖于透明的修改并且不需要对现有基础架构进行任何更改。 透明代理通过提取源IP地址和目的IP地址来确定数据包是发送给特定用户还是从特定用户发送，并将结果传递给调度机制。
2）Token-bucket Scheduling: As the final step of achieving the go-as-you-pay design, the scheduling mechanism assigns the exact bandwidth and data burst specified by allocation computation. Token-bucket algorithm [31] checks whether data transmission in the form of packets conforms to defined limits on bandwidth and burstiness. Each user is virtually assigned a bucket, with tokens added at a certain rate. Whenever a packet is transmitted, tokens are removed from the bucket, and the number is equivalent to the size of the packet. Packets might be delayed or dropped if there are no enough tokens
Intuitively, the increasing rate of tokens controls the available bandwidth, while the capacity of the bucket represents the maximum volume of data burst. Users could always utilize the data burst as long as the buckets are not empty; once the bucket is empty, the achievable throughput of a user is constrained by her allocated bandwidth. Our control is on both sent and received packets and is thus bidirectional. Once the bucket is full, tokens can no longer be added and part of the rate is wasted. By monitoring the portion of the wasted token-adding rate, we can know the portion of idle bandwidth.
2）令牌 桶调度：作为实现按需付费设计的最后一步，调度机制分配分配计算指定的确切带宽和数据突发。令牌桶算法[31]检查数据包形式的数据传输是否符合定义的带宽和突发性限制。每个用户都被虚拟地分配了一个桶，并以一定的速率添加令牌。每当一个数据包被传输时，**令牌就会从桶中被移除，其数量就相当于数据包的大小。**如果没有足够的令牌，数据包可能会延迟或丢弃
直观地说，令牌的增加速率控制了可用带宽，而桶的容量代表了数据突发的最大量。只要桶不为空，用户就可以随时利用数据突发；一旦桶为空，用户可实现的吞吐量就会受到她分配的带宽的限制。我们的控制是发送和接收的数据包，因此是双向的。一旦桶满了，就不能再添加令牌，并且浪费了一部分费率。通过监控浪费的令牌添加率部分，我们可以知道空闲带宽的部分。
3）Feedback: We design a feedback mechanism to better utilize the limited bandwidth. Following the token-bucket scheduling mechanism, we monitor the buckets for the utilization level of bandwidth. Since the average value during a period better characterizes the utilization than the instantaneous values, we apply a sliding window in implementation. If the average ratio of idle bandwidth exceeds a certain threshold, the user will be suggested to request less bandwidth. The feedback results are also used by the scheduling module itself. It aggregates unutilized tokens and redistributes them among users without tokens overflowing their buckets. The quantities are still proportional to the demand, conforming to our original allocation mechanism. As a compensation, users with their idle bandwidth redistributed will be charged a discounted fee based on the actual utilized bandwidth. However, additional usage fee will not be incurred for users allocated with such idle bandwidth, as the redistribution is temporary and mainly for improving the resource utilization for the owner.
3）反馈：我们设计了一个反馈机制来更好地利用有限的带宽。遵循令牌桶调度机制，我们监控桶的带宽利用率水平。由于一段时间内的平均值比瞬时值更能表征利用率，因此我们在实现中应用了滑动窗口。如果空闲带宽的平均比例超过某个阈值，则会建议用户减少请求带宽。反馈结果也被调度模块本身使用。它聚合未使用的令牌并在用户之间重新分配它们，而令牌不会溢出他们的存储桶。数量仍然与需求成正比，符合我们原来的分配机制。作为补偿，重新分配空闲带宽的用户将根据实际使用的带宽收取折扣费用。但是，分配到这种空闲带宽的用户不会产生额外的使用费，因为重新分配是暂时的，主要是为了提高所有者的资源利用率。
4）Adaptive Connection: Based on the feedback mechanism, we implement the optional function that provides autodetection of varying user demand and adaptive adjustment of user request. As is mentioned in Section III-A1, DiFi offers several pre-configured levels of demand for connection quality, e.g., 4 Mbps bandwidth for streaming normal videos and 10 Mbps for streaming HD videos. If a user has opted in and DiFi detects that the utilization exceeds the upper threshold, e.g., 90%, within a sliding window of certain length, e.g., around 10s, it automatically adjusts the user’s demand to the higher level. On the contrary, if the utilization is below the lower threshold, e.g., 30% of the bandwidth at the lower level, it also downgrades the user demand accordingly,
4）自适应连接：基于反馈机制，我们实现了可选功能，提供自动检测变化的用户需求和自适应调整用户请求的功能。 如第 III-A1 节所述，DiFi 提供了几个预先配置的连接质量需求级别，例如，4 Mbps 带宽用于流式传输普通视频和 10 Mbps 用于流式传输高清视频。 如果用户选择加入，DiFi 在一定长度的滑动窗口内（例如 10s 左右）检测到利用率超过上限阈值，例如 90%，它会自动将用户的需求调整到更高的水平。 相反，如果利用率低于下限阈值，例如下限带宽的 30%，也会相应地降低用户需求，
D. User Interface
1）Server and Web UI: DiFi provides a web-based user interface that handles direct communication with users. Users indicate requirement and view status of the connection via the web UI. The status includes prices, allocated resources, current balances, etc. Figure 2 provides an example of the web page for users to submit their demand. Users may also use the optional functions of DiFi, such as specifying particular desired bandwidth and data burst, and opting in or out of the adaptive connection introduced in the previous section. The Raspberry Pi works as the server that supports the web UI.
1）服务器和Web UI：DiFi提供了一个基于Web的用户界面来处理与用户的直接通信。 用户通过 Web UI 指示连接的要求和查看状态。 状态包括价格、分配的资源、当前余额等。图 2 提供了一个网页示例，供用户提交他们的需求。 用户还可以使用 DiFi 的可选功能，例如指定特定的所需带宽和数据突发，以及选择加入或退出上一节介绍的自适应连接。 Raspberry Pi 用作支持 Web UI 的服务器。