Page 66 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

Therefore, there is a need for a lightweight solution that 2. RELATED WORK
will enable resource‑constrained IoT devices to utilize LN
for micro‑payments. To this end, in this paper, we pro‑ The closest work to ours is from Hannon and Jin [11].
pose an ef icient and secure protocol where an IoT device They propose to employ LN‑like payment channels to give
can connect to an untrusted LN gateway that already hosts IoT devices the ability to perform off‑chain transactions.
the full LN and Bitcoin nodes and can: 1) open/close LN Since an IoT device does not have access to the blockchain,
channels and 2) send payments on behalf of the IoT device they use a pool of two different third parties which are
when requested. Our approach is similar to a delegation called the IoT payment gateway and watchdog to aid the
approach which comes with almost negligible computa‑ IoT device in the process. Using game theory, they show
tion and communication overheads for the IoT devices. that the protocol reaches an equilibrium given that the
We are proposing to incentivize the LN gateway to partic‑ players follow the protocol. However, this approach has a
ipate in this payment service by letting it charge IoT de‑ major issue: They assume that the IoT device can actually
vices for each payment it processes. open LN‑like payment channels to the IoT gateway. While
it is not clear how it can be done, the authors also do not
In our proposed protocol, we introduce the concept of have a proof of concept implementation of the approach
3‑of‑3 multisignature LN channels, which involves signa‑ which is another puzzling aspect of the work.
tures of all three channel parties (i.e., the IoT device, the Robert et al. [12] proposed IoTBnB, a digital IoT market‑
LN gateway, and a bridge LN node to which the LN gate‑ place, to let data trading between the data owners and the
way opens a channel for the IoT device) to conduct any users. In their scheme, after the user selects which item to
operation on the channel as opposed to using the LN’s buy from the marketplace, it is redirected to an LN mod‑
original 2‑of‑2 multisignature channels. This modi ica‑ ule that performs the payment. This LN module is host‑
tion to the channels is possible by changing the LN’s Bit‑ ing the full Bitcoin and LN nodes. However, the authors
coin scripts which play a critical role in our protocol as it are focused on integrating LN into an existing IoT ecosys‑
prevents the LN gateway from spending the IoT device’s tem rather than enabling individual IoT devices to use LN
funds. More ically, the LN gateway cannot spend that are not part of such an ecosystem. Additionally, in
the IoT device’s funds in the channel without getting the their system, the IoT device’s funds are held by wallets
IoT device’s cryptographic signature which consequently belonging to the ecosystem which raises security and pri‑
means that the IoT device’s funds are secure at all times. vacy concerns. In our work, we cover a broader aspect
Since LN’s original protocol is modi ied, this also necessi‑ of IoT applications and IoT’s funds are not held by third
tates revisiting the revoked state broadcast issue of LN. We parties.
offer revisions to protect the IoT device’s funds in revoked A different work focusing on Ethereum micro‑payments
state broadcast attempts when 3‑of‑3 multisignature LN rather than Bitcoin was proposed by Pouraghily and Wolf
channels are used. [13]. They employ a Ticket‑Based V ication Protocol
(TBVP) for a similar purpose, enabling IoT devices to per‑
To assess the effectiveness and overhead of the proposed form inancial transactions in an IoT ecosystem. By us‑
protocol, we implemented it within a setup where a Rasp‑ ing two entities called contract manager and transaction
berry Pi sends LN payments to a real LN node through a v ier, attempts are made to reduce the performance
wireless connection. We considered two real‑life cases in requirements on the IoT devices. There are some is‑
the experiments: a vehicle at a certain speed making a toll sues with this approach: 1) It is mentioned that the IoT
payment through a wireless connection and a customer funds are deposited into an account jointly opened with
paying for a coffee at a coffee shop using his/her smart‑ a partner device. Since the details are not provided, it
watch. We demonstrated that the proposed protocol en‑ raises security and privacy concerns. 2) The scheme uti‑
ables the realization of timely payments with negligible lizes Ethereum smart contracts and TBVP was compared
computational and communication delays. We separately with Raiden [14] which is an Ethereum payment chan‑
provide a security analysis of the proposed protocol. nel framework targeting low‑end devices. However, this

comparison might not be reliable as Raiden develop‑
The structure of the rest of the paper is as follows. In Sec‑ ment was dormant for more than 2 years. In our work,
tion 2, we provide the related work. Section 3 describes we targeted Bitcoin and LN which are actively being de‑
the LN, its underlying mechanisms and its protocol spec‑ veloped and currently dominating the market.
ications. System and threat model are explained in Sec‑ A recent work by Profentzas et al. [15] proposes TinyEVM,
tion 4. We explain the proposed protocol in detail in Sec‑ an Ethereum based off‑chain smart contract system to en‑
tion 5. Security analysis against the assumed threats is able IoT devices to perform micro‑payments. The authors
provided in Section 6. We present our evaluation results tried to tackle the problem by modifying Ethereum vir‑
for the proposed protocol in Section 7. Finally, the paper
tual machine and running it on the IoT device. In our ap‑
is concluded in Section 8.
proach, we only require the IoT device to generate sig‑
natures, which is not a resource‑intensive operation. An‑
other work, [16], focuses on data transactions for IoT us‑
ing payment channels. A slightly different work by

54 © International Telecommunication Union, 2021