OE
O. Ersoy
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
14 records found
1
Payment channel networks (PCNs) are a promising solution to the blockchain scalability problem. They move payments off-chain, i.e., not all payments have to be included in the blockchain. Thus, they do not require that every payment is broadcast to all participants and verified by them. Not requiring global consensus reduces latency, computation, and hence energy consumption.
In PCNs, a payer can route a multi-hop payment to a payee via intermediaries. Yet, Lightning, the only prominent payment channel network, has two major issues when it comes to multi-hop payments. First, the payer decides on the path without being able to take local capacity restrictions into account. Second, due to the atomicity of payments, any failure in the path causes a failure of the complete payment. While there are suggested solutions for each of these problems --- namely splitting payments, local routing, and adding redundancy ---, there is no solution that solves both of them.
In this work, we propose JustForward: The payer adds redundancy to the payment by initially committing to sending a higher amount than the actual payment value $v$. Intermediaries decide on how to forward a received payment, potentially splitting it between multiple paths. If they cannot (or do not want to) forward the complete payment value, they may reduce the amount they forward. If paths for at least $v$ coins are found, the receiver and source jointly select the amounts of sub-payments that make up the full payment. Payment commitments are updated accordingly and fulfilled. In order to guarantee atomicity and correctness of the payment value, we use a modified Hashed Time Lock Contract (HTLC) for paying that requires both the payer and the payee to provide a secret pre-image. JustForward furthermore is the first local routing protocol to include fees: The source adds a maximal amount of fees they are willing to pay to the payment. Intermediaries take fees as they see fit, taking into consideration that subsequent nodes on the path will not forward the payment if there are insufficient fees left.
We prove that the proposed protocol achieves balance security, atomicity, bounded loss for the sender, and optionally unlinkability of split sub-payments of the same overall payments. Furthermore, our evaluation on both synthetic and real-world Lightning topologies shows JustForward outperforms existing algorithms in terms of the fraction of successful payments as long as the degree of redundancy is not too high. Concretely, for a moderate amount of redundancy, JustForward increases the success ratio of payments by about 10%. ...
In PCNs, a payer can route a multi-hop payment to a payee via intermediaries. Yet, Lightning, the only prominent payment channel network, has two major issues when it comes to multi-hop payments. First, the payer decides on the path without being able to take local capacity restrictions into account. Second, due to the atomicity of payments, any failure in the path causes a failure of the complete payment. While there are suggested solutions for each of these problems --- namely splitting payments, local routing, and adding redundancy ---, there is no solution that solves both of them.
In this work, we propose JustForward: The payer adds redundancy to the payment by initially committing to sending a higher amount than the actual payment value $v$. Intermediaries decide on how to forward a received payment, potentially splitting it between multiple paths. If they cannot (or do not want to) forward the complete payment value, they may reduce the amount they forward. If paths for at least $v$ coins are found, the receiver and source jointly select the amounts of sub-payments that make up the full payment. Payment commitments are updated accordingly and fulfilled. In order to guarantee atomicity and correctness of the payment value, we use a modified Hashed Time Lock Contract (HTLC) for paying that requires both the payer and the payee to provide a secret pre-image. JustForward furthermore is the first local routing protocol to include fees: The source adds a maximal amount of fees they are willing to pay to the payment. Intermediaries take fees as they see fit, taking into consideration that subsequent nodes on the path will not forward the payment if there are insufficient fees left.
We prove that the proposed protocol achieves balance security, atomicity, bounded loss for the sender, and optionally unlinkability of split sub-payments of the same overall payments. Furthermore, our evaluation on both synthetic and real-world Lightning topologies shows JustForward outperforms existing algorithms in terms of the fraction of successful payments as long as the degree of redundancy is not too high. Concretely, for a moderate amount of redundancy, JustForward increases the success ratio of payments by about 10%. ...
Payment channel networks (PCNs) are a promising solution to the blockchain scalability problem. They move payments off-chain, i.e., not all payments have to be included in the blockchain. Thus, they do not require that every payment is broadcast to all participants and verified by them. Not requiring global consensus reduces latency, computation, and hence energy consumption.
In PCNs, a payer can route a multi-hop payment to a payee via intermediaries. Yet, Lightning, the only prominent payment channel network, has two major issues when it comes to multi-hop payments. First, the payer decides on the path without being able to take local capacity restrictions into account. Second, due to the atomicity of payments, any failure in the path causes a failure of the complete payment. While there are suggested solutions for each of these problems --- namely splitting payments, local routing, and adding redundancy ---, there is no solution that solves both of them.
In this work, we propose JustForward: The payer adds redundancy to the payment by initially committing to sending a higher amount than the actual payment value $v$. Intermediaries decide on how to forward a received payment, potentially splitting it between multiple paths. If they cannot (or do not want to) forward the complete payment value, they may reduce the amount they forward. If paths for at least $v$ coins are found, the receiver and source jointly select the amounts of sub-payments that make up the full payment. Payment commitments are updated accordingly and fulfilled. In order to guarantee atomicity and correctness of the payment value, we use a modified Hashed Time Lock Contract (HTLC) for paying that requires both the payer and the payee to provide a secret pre-image. JustForward furthermore is the first local routing protocol to include fees: The source adds a maximal amount of fees they are willing to pay to the payment. Intermediaries take fees as they see fit, taking into consideration that subsequent nodes on the path will not forward the payment if there are insufficient fees left.
We prove that the proposed protocol achieves balance security, atomicity, bounded loss for the sender, and optionally unlinkability of split sub-payments of the same overall payments. Furthermore, our evaluation on both synthetic and real-world Lightning topologies shows JustForward outperforms existing algorithms in terms of the fraction of successful payments as long as the degree of redundancy is not too high. Concretely, for a moderate amount of redundancy, JustForward increases the success ratio of payments by about 10%.
In PCNs, a payer can route a multi-hop payment to a payee via intermediaries. Yet, Lightning, the only prominent payment channel network, has two major issues when it comes to multi-hop payments. First, the payer decides on the path without being able to take local capacity restrictions into account. Second, due to the atomicity of payments, any failure in the path causes a failure of the complete payment. While there are suggested solutions for each of these problems --- namely splitting payments, local routing, and adding redundancy ---, there is no solution that solves both of them.
In this work, we propose JustForward: The payer adds redundancy to the payment by initially committing to sending a higher amount than the actual payment value $v$. Intermediaries decide on how to forward a received payment, potentially splitting it between multiple paths. If they cannot (or do not want to) forward the complete payment value, they may reduce the amount they forward. If paths for at least $v$ coins are found, the receiver and source jointly select the amounts of sub-payments that make up the full payment. Payment commitments are updated accordingly and fulfilled. In order to guarantee atomicity and correctness of the payment value, we use a modified Hashed Time Lock Contract (HTLC) for paying that requires both the payer and the payee to provide a secret pre-image. JustForward furthermore is the first local routing protocol to include fees: The source adds a maximal amount of fees they are willing to pay to the payment. Intermediaries take fees as they see fit, taking into consideration that subsequent nodes on the path will not forward the payment if there are insufficient fees left.
We prove that the proposed protocol achieves balance security, atomicity, bounded loss for the sender, and optionally unlinkability of split sub-payments of the same overall payments. Furthermore, our evaluation on both synthetic and real-world Lightning topologies shows JustForward outperforms existing algorithms in terms of the fraction of successful payments as long as the degree of redundancy is not too high. Concretely, for a moderate amount of redundancy, JustForward increases the success ratio of payments by about 10%.
Blockchain technology is the underlying mechanism that many cryptocurrencies operate on. It relies on cryptographic techniques that enforce integrity on transaction records. The records (blocks) stored are limited in size and frequency. One well-known issue regarding blockchain technology is the lack of scalability. In order to mitigate this problem, payment channels were introduced. These are considered an "off-chain" solution as communication with the blockchain is not required for executing transactions. Nonetheless, payment channels are debit-based, thus each channel that contributes to forwarding the payment is required to have a sufficient amount of coins to route the money. If this is not the case, the transaction may not succeed. For solving this matter, the node may decide to split the payment and forward it through multiple intermediaries until the destination is reached. This paper studies how fee models can be integrated into splitting protocols. An overview of the current state of the technology is provided, followed by a proposed solution for integrating fees into splitting protocols. It has been observed that splitting the payments and charging lower fees leads to a higher number of successful transactions, an outcome that was expected. The proposed fee model relies on the payment value and a statistic about the distribution of coins owned by the involved parties. The highest success ratio was achieved when combining the proposed design with the SplitIfNecessary splitting protocol. Nonetheless, when using the same fee model, there does not seem to be any pattern between the splitting protocol and the transaction value.
...
...
Blockchain technology is the underlying mechanism that many cryptocurrencies operate on. It relies on cryptographic techniques that enforce integrity on transaction records. The records (blocks) stored are limited in size and frequency. One well-known issue regarding blockchain technology is the lack of scalability. In order to mitigate this problem, payment channels were introduced. These are considered an "off-chain" solution as communication with the blockchain is not required for executing transactions. Nonetheless, payment channels are debit-based, thus each channel that contributes to forwarding the payment is required to have a sufficient amount of coins to route the money. If this is not the case, the transaction may not succeed. For solving this matter, the node may decide to split the payment and forward it through multiple intermediaries until the destination is reached. This paper studies how fee models can be integrated into splitting protocols. An overview of the current state of the technology is provided, followed by a proposed solution for integrating fees into splitting protocols. It has been observed that splitting the payments and charging lower fees leads to a higher number of successful transactions, an outcome that was expected. The proposed fee model relies on the payment value and a statistic about the distribution of coins owned by the involved parties. The highest success ratio was achieved when combining the proposed design with the SplitIfNecessary splitting protocol. Nonetheless, when using the same fee model, there does not seem to be any pattern between the splitting protocol and the transaction value.
Blockchains like Bitcoin are known to be victim of scalability issues. The lack in high throughput and low latency form a great bottleneck to its network. A promis- ing solution are layer 2 protocols, more precisely payment channel networks (PCN). Payment success rates are a common metric in these networks. These rates can be in- creased by tweaking the routing of payments in the network. Local routing is a form of routing that allows payments in such networks to be split over multiple paths to reach its receiver. This significantly increases the rate of payment successes, however there is no trivial way to integrate fees in such protocol. This paper focuses on the integration of fees in local routing protocols by proposing a viable solution. Local Routing Fee Protocol (LRFP) is a protocol designed to extend an existing local routing protocol and is proven to be secure. It is a light addition but works as intended. Proofs on se- curity guarantees and a formal description on the protocol form the main contribution of this paper.
...
Blockchains like Bitcoin are known to be victim of scalability issues. The lack in high throughput and low latency form a great bottleneck to its network. A promis- ing solution are layer 2 protocols, more precisely payment channel networks (PCN). Payment success rates are a common metric in these networks. These rates can be in- creased by tweaking the routing of payments in the network. Local routing is a form of routing that allows payments in such networks to be split over multiple paths to reach its receiver. This significantly increases the rate of payment successes, however there is no trivial way to integrate fees in such protocol. This paper focuses on the integration of fees in local routing protocols by proposing a viable solution. Local Routing Fee Protocol (LRFP) is a protocol designed to extend an existing local routing protocol and is proven to be secure. It is a light addition but works as intended. Proofs on se- curity guarantees and a formal description on the protocol form the main contribution of this paper.
The largest payment channel network, Bitcoin Lightning, shows a potential alternative to cur- rent financial systems, overcoming the scalability limitations of blockchain. Source onion routing is used to route payments, but novel routing protocols claim improved effectiveness by employ- ing strategies not compatible with the current state of affairs. In this paper, we compare the current implementations deployed in the Lightning Network, with a novel routing algorithm with splitting and local routing. We find the latter option to significantly boost the success ratio of payments, while inducing some monetary overhead. Then, we propose future directions of research on Lightning protocols to boost their performance.
...
...
The largest payment channel network, Bitcoin Lightning, shows a potential alternative to cur- rent financial systems, overcoming the scalability limitations of blockchain. Source onion routing is used to route payments, but novel routing protocols claim improved effectiveness by employ- ing strategies not compatible with the current state of affairs. In this paper, we compare the current implementations deployed in the Lightning Network, with a novel routing algorithm with splitting and local routing. We find the latter option to significantly boost the success ratio of payments, while inducing some monetary overhead. Then, we propose future directions of research on Lightning protocols to boost their performance.
Front-running is the illegal practice of obtaining information unavailable to the general public with regards to upcoming transactions and performing actions based on this knowledge as to gain profit. This type of attack has been an issue since the introduction of the first stock market and it is not a surprise it has spread into blockchain technologies. With the invention of Decentralized Exchange Systems, this type of exploit has been an even more common occurrence that puts both the user and system at a disadvantage. This paper aims to explore the circumstances that enable front-running in UniSwap, one of the most used DeFi Systems as of the writing of this paper. Factors such as lack of privacy, slippage, as well as a miner’s role in the exploit are analysed in a broad and UniSwap-centered context to provide more insight to the problem. Moreover, this paper analyses a potential adjustment of a commit-reveal scheme, a time lock scheme, and off-chain slippage limit as possible solutions and an overall analysis of the proposed solutions. Through comparison and adjustments of different solutions, this paper strives to expose where the root of the problem lies - the Ethereum blockchain itself.
...
Front-running is the illegal practice of obtaining information unavailable to the general public with regards to upcoming transactions and performing actions based on this knowledge as to gain profit. This type of attack has been an issue since the introduction of the first stock market and it is not a surprise it has spread into blockchain technologies. With the invention of Decentralized Exchange Systems, this type of exploit has been an even more common occurrence that puts both the user and system at a disadvantage. This paper aims to explore the circumstances that enable front-running in UniSwap, one of the most used DeFi Systems as of the writing of this paper. Factors such as lack of privacy, slippage, as well as a miner’s role in the exploit are analysed in a broad and UniSwap-centered context to provide more insight to the problem. Moreover, this paper analyses a potential adjustment of a commit-reveal scheme, a time lock scheme, and off-chain slippage limit as possible solutions and an overall analysis of the proposed solutions. Through comparison and adjustments of different solutions, this paper strives to expose where the root of the problem lies - the Ethereum blockchain itself.
Popular cryptocurrencies lack scalability. Payment Channel Networks (PCN's) allow a large increase in transaction throughput. However, transaction failures are frequent when transactions are routed through multiple intermediaries. A previously introduced protocol, Interdimensional SpeedyMurmurs, increased the success ratio of transactions in PCN's by allowing routing to be more flexible and transactions to be split into multiple smaller transactions. This protocol also introduced several methods of splitting transactions that increased the success ratio even further in the short term. The splitting methods were not good for the short term as they often depleted channels completely. This paper aims to introduce novel methods of splitting transactions that easily integrate into Interdimensional SpeedyMurmurs in order to increase the success ratio in the long term. A thorough evaluation of the novel splitting methods was conducted using simulations on a snapshot of a real-world used PCN. In one scenario an increase of 2.4% over previous methods was achieved.
...
Popular cryptocurrencies lack scalability. Payment Channel Networks (PCN's) allow a large increase in transaction throughput. However, transaction failures are frequent when transactions are routed through multiple intermediaries. A previously introduced protocol, Interdimensional SpeedyMurmurs, increased the success ratio of transactions in PCN's by allowing routing to be more flexible and transactions to be split into multiple smaller transactions. This protocol also introduced several methods of splitting transactions that increased the success ratio even further in the short term. The splitting methods were not good for the short term as they often depleted channels completely. This paper aims to introduce novel methods of splitting transactions that easily integrate into Interdimensional SpeedyMurmurs in order to increase the success ratio in the long term. A thorough evaluation of the novel splitting methods was conducted using simulations on a snapshot of a real-world used PCN. In one scenario an increase of 2.4% over previous methods was achieved.
Payment Channel Networks have been developed to deal with the scalability issue in blockchain technologies. Using them, two parties can make multiple payments between themselves relatively fast. However, usually the channels have too small capacities, unable to handle a big payment. Allowing to split a payment into smaller payments and forwarding them through different intermediaries is a way to solve this issue, but a party only knows the capacities of the channels it is connected to. Therefore, it is possible for a payment to be sent to an intermediary which would not have sufficient funds to forward it to another node, closer to the receiver. Making redundant transactions in order to further improve the payment success ratio is a way to handle this drawback. This paper provides 3 algorithms for adding redundancy to the already existing splitting protocol. The evaluation shows that all of them improve the success ratio, but at the price of parties exchanging more messages.
...
Payment Channel Networks have been developed to deal with the scalability issue in blockchain technologies. Using them, two parties can make multiple payments between themselves relatively fast. However, usually the channels have too small capacities, unable to handle a big payment. Allowing to split a payment into smaller payments and forwarding them through different intermediaries is a way to solve this issue, but a party only knows the capacities of the channels it is connected to. Therefore, it is possible for a payment to be sent to an intermediary which would not have sufficient funds to forward it to another node, closer to the receiver. Making redundant transactions in order to further improve the payment success ratio is a way to handle this drawback. This paper provides 3 algorithms for adding redundancy to the already existing splitting protocol. The evaluation shows that all of them improve the success ratio, but at the price of parties exchanging more messages.
Oracles are mechanisms that provide blockchain networks with data that only exists outside of the network, such as asset prices. Decentralized Finance (DeFi) protocols use this data, and therefore their usability depends on the reliability of oracles. One such oracle system, widely used by DeFi protocols for pricing feeds, is Chainlink. The Chainlink system mitigates the risk of oracle manipulation attacks that have occurred in various DeFi protocols with a decentralized data aggregation infrastructure. The participants of the Chainlink system are incentivized by a coordination game, which poses game theoretic risks. While some game theoretic analyses of blockchain based systems exist, no formal study has been done on the incentives securing the Chainlink system. In this paper, we present a formal incentive model of the participants in the Chainlink system. We show that users can not detect whether incentives are aligned such that honest node behaviour is a strictly dominant strategy, making it impossible for users to assess the security of the system. We propose a mitigation which enables users to assess the agent incentives of Chainlink nodes such that they can verify whether honest behaviour is a strictly dominant strategy for all participants.
...
Oracles are mechanisms that provide blockchain networks with data that only exists outside of the network, such as asset prices. Decentralized Finance (DeFi) protocols use this data, and therefore their usability depends on the reliability of oracles. One such oracle system, widely used by DeFi protocols for pricing feeds, is Chainlink. The Chainlink system mitigates the risk of oracle manipulation attacks that have occurred in various DeFi protocols with a decentralized data aggregation infrastructure. The participants of the Chainlink system are incentivized by a coordination game, which poses game theoretic risks. While some game theoretic analyses of blockchain based systems exist, no formal study has been done on the incentives securing the Chainlink system. In this paper, we present a formal incentive model of the participants in the Chainlink system. We show that users can not detect whether incentives are aligned such that honest node behaviour is a strictly dominant strategy, making it impossible for users to assess the security of the system. We propose a mitigation which enables users to assess the agent incentives of Chainlink nodes such that they can verify whether honest behaviour is a strictly dominant strategy for all participants.
Reentrancy attacks target smart contracts of Decentralized Finance systems that contain coding errors caused by developers. This type of attacks caused, in the past 5 years, the loss of over 400 million USD. Several countermeasures were developed that use patterns to detect reentrancy attacks on smart contracts before deployment on the Ethereum blockchain. However, the smart contracts are by default public and immutable once deployed on the blockchain. That is why the research question is: How can we protect smart contracts of DeFi systems deployed on the Ethereum blockchain that are known to be vulnerable to reentrancy attacks? A solution that detects reentrancy attacks on smart contracts after their deployment is presented in this paper. It flags transactions when a difference is found between the users' funds on both the application and protocol layers before and after each transaction using special made smart wallets. A proof of concept shows that the proposed solution can detect reentrancy attempts and stop them during the execution phase of smart contracts.
...
Reentrancy attacks target smart contracts of Decentralized Finance systems that contain coding errors caused by developers. This type of attacks caused, in the past 5 years, the loss of over 400 million USD. Several countermeasures were developed that use patterns to detect reentrancy attacks on smart contracts before deployment on the Ethereum blockchain. However, the smart contracts are by default public and immutable once deployed on the blockchain. That is why the research question is: How can we protect smart contracts of DeFi systems deployed on the Ethereum blockchain that are known to be vulnerable to reentrancy attacks? A solution that detects reentrancy attacks on smart contracts after their deployment is presented in this paper. It flags transactions when a difference is found between the users' funds on both the application and protocol layers before and after each transaction using special made smart wallets. A proof of concept shows that the proposed solution can detect reentrancy attempts and stop them during the execution phase of smart contracts.
Kyber is a Decentralized Finance (DeFi) system which runs on the Ethereum blockchain. DeFi aims to remove centralized intermediaries such as Market Makers. An Automated Market Maker (AMM), implemented in a smart contract, is a decentralized version of these. Kyber's Dynamic Market Maker (DMM) is a next-generation AMM which solves two issues: Capital Inefficiency (CI) and Impermanent Loss (IL). CI is decreased by an amplification factor which a Liquidity Provider sets upon creaton of a liquidity pool, whereas IL is decreased by dynamic fees. A DMM features two reserves: one real reserve that reflects the true amounts of the two tokens in the pool and one virtual reserve that reflects the amounts after the amplification factor is applied. The vulnerability to a sandwich attack exists because the virtual reserve ratio can be unbalanced by an attacker. This results in slippage for the victim when their transaction gets executed. Finally, the attacker can perform a swap using the incorrect ratio. The research question of this paper is: How can one mitigate sandwich attacks in Kyber DMM? Kyber's current mitigation features slippage protection to protect users from sandwich attacks. The slippage protection is implemented by adding two parameters to the function used when adding liquidity: one for specifying the lower bound for the virtual reserve ratio and one for specifying the upper bound. However, this mitigation is only present in the router. Therefore, users interacting with the pool contract directly remain vulnerable. To show that this is true, we modify Kyber's test case for sandwich attacks to encompass the mint function in the pool contract. The existing mitigation can be broadened by implementing a code correction in the mint function like the one present in the function used when adding liquidity.
...
Kyber is a Decentralized Finance (DeFi) system which runs on the Ethereum blockchain. DeFi aims to remove centralized intermediaries such as Market Makers. An Automated Market Maker (AMM), implemented in a smart contract, is a decentralized version of these. Kyber's Dynamic Market Maker (DMM) is a next-generation AMM which solves two issues: Capital Inefficiency (CI) and Impermanent Loss (IL). CI is decreased by an amplification factor which a Liquidity Provider sets upon creaton of a liquidity pool, whereas IL is decreased by dynamic fees. A DMM features two reserves: one real reserve that reflects the true amounts of the two tokens in the pool and one virtual reserve that reflects the amounts after the amplification factor is applied. The vulnerability to a sandwich attack exists because the virtual reserve ratio can be unbalanced by an attacker. This results in slippage for the victim when their transaction gets executed. Finally, the attacker can perform a swap using the incorrect ratio. The research question of this paper is: How can one mitigate sandwich attacks in Kyber DMM? Kyber's current mitigation features slippage protection to protect users from sandwich attacks. The slippage protection is implemented by adding two parameters to the function used when adding liquidity: one for specifying the lower bound for the virtual reserve ratio and one for specifying the upper bound. However, this mitigation is only present in the router. Therefore, users interacting with the pool contract directly remain vulnerable. To show that this is true, we modify Kyber's test case for sandwich attacks to encompass the mint function in the pool contract. The existing mitigation can be broadened by implementing a code correction in the mint function like the one present in the function used when adding liquidity.
Bubblechain
An IoT authentication system
Authentication of domains has been a crucial part of the growth of web browsing, especially for e-commerce and secure browsing. However, the digital space has expanded from web domains to include devices such as smart cars, smart houses, and other IoT devices. The future for these devices is to communicate autonomously with one another, also known as Machine-to-Machine(M2M) communication. For M2M communication, IoT devices need to be able to authenticate each other. However, IoT devices cannot take over traditional authentication mechanisms. This problem is due to the expected growth in the number of IoT devices and the varying resource capabilities of these devices. In this work, we introduce Bubblechain, a generic, decentralised, and scalable IoT authentication system. In contrast to existing works, Bubblechain can update and remove identities of IoT devices that allows them to authenticate each other in a dynamic setting. Bubblechain also creates a higher trust level for devices that belong to the same Bubble. A Bubble refers to a group of devices that belong together, such as a home or office setting. The system also provides the possibility to authenticate devices from different Bubbles. The authentication process in Bubblechain is autonomous and decentralised.
...
Authentication of domains has been a crucial part of the growth of web browsing, especially for e-commerce and secure browsing. However, the digital space has expanded from web domains to include devices such as smart cars, smart houses, and other IoT devices. The future for these devices is to communicate autonomously with one another, also known as Machine-to-Machine(M2M) communication. For M2M communication, IoT devices need to be able to authenticate each other. However, IoT devices cannot take over traditional authentication mechanisms. This problem is due to the expected growth in the number of IoT devices and the varying resource capabilities of these devices. In this work, we introduce Bubblechain, a generic, decentralised, and scalable IoT authentication system. In contrast to existing works, Bubblechain can update and remove identities of IoT devices that allows them to authenticate each other in a dynamic setting. Bubblechain also creates a higher trust level for devices that belong to the same Bubble. A Bubble refers to a group of devices that belong together, such as a home or office setting. The system also provides the possibility to authenticate devices from different Bubbles. The authentication process in Bubblechain is autonomous and decentralised.
Protocols for Loanable Funds (PLFs) are lending protocols that exist in the decentralized finance (DeFi) ecosystem. They provide users the opportunity of lending and borrowing of cryptocurrencies. The economic model used to ensure liquidity in these protocols are variable parameters and incentives to reach an optimal equilibrium and overcollateralization to make trust between participants unnecessary. However, the design of this protocol can show signs of illiquidity in which the safeguards of the protocol do not function as expected in times of an unfavourable market. In this paper, the liquidity of Aave, one of the biggest PLFs, is empirically examined. A game theoretical model is used to analyze the behaviour of participants to the various incentives in the protocol. Firstly, the potential points of failure in case of a bear market with a volatile asset are evaluated. Secondly, the mechanisms for mitigation of illiquidity in the Aave protocol are examined. Ultimately, diversification of the assets in the safety module is proposed to increase the efficiency of the safety module and therefore decrease the risk of illiquidity in the protocol.
...
Protocols for Loanable Funds (PLFs) are lending protocols that exist in the decentralized finance (DeFi) ecosystem. They provide users the opportunity of lending and borrowing of cryptocurrencies. The economic model used to ensure liquidity in these protocols are variable parameters and incentives to reach an optimal equilibrium and overcollateralization to make trust between participants unnecessary. However, the design of this protocol can show signs of illiquidity in which the safeguards of the protocol do not function as expected in times of an unfavourable market. In this paper, the liquidity of Aave, one of the biggest PLFs, is empirically examined. A game theoretical model is used to analyze the behaviour of participants to the various incentives in the protocol. Firstly, the potential points of failure in case of a bear market with a volatile asset are evaluated. Secondly, the mechanisms for mitigation of illiquidity in the Aave protocol are examined. Ultimately, diversification of the assets in the safety module is proposed to increase the efficiency of the safety module and therefore decrease the risk of illiquidity in the protocol.
Smart contracts are applications that are deployed and executed on a blockchain's decentralised infrastructure. Many smart contract applications rely on data that resides outside the blockchain. However, while traditional web applications can communicate with trustworthy data sources directly through the Internet, this is not possible for smart contracts because their execution must be deterministic. Bringing external data into the blockchain has been a topic of research since the first introduction of Ethereum, and a system that can provide this data to smart contracts is called an oracle. The primary requirement in designing oracles is that the authenticity of the data must be publicly verifiable, which can be achieved through signatures. However, transmitting data to the blockchain and performing the verification is costly, especially if applications require data from multiple sources as, in that case, current approaches would need to retrieve the data from each source separately.
This research aims to reduce the cost of retrieving external data for smart contracts from multiple sources while ensuring that the authenticity of the data is publicly verifiable. Two factors influence the total cost. The first is the size of the data, which determines the cost of transmitting the data to the blockchain and storing it, while the second factor is the cost of verifying the authenticity. In this work, we focused on the first factor, as transmission and storage of data are among Ethereum's most expensive operations.
We present two oracles for retrieving data from multiple sources, which we believe to be the first to focus on the multi-source scenario. The oracles both lower the cost of retrieving external data by compressing the proofs of the data's authenticity using aggregate signatures. Even though the oracles achieve the same goal, they are based on different primitives. The first uses bilinear pairings and produces an aggregate signature of constant size, regardless of the number of data sources that are involved. The second is based on the more standard assumption of trapdoor permutations. However, the aggregate signature grows slightly with the number of signers, and the oracle must interact with the data sources sequentially. We confirm the feasibility of our work by implementing and practically evaluating the two oracles in the Solidity programming language. Our experiments show that both oracles expend less gas than non-aggregating oracles based on the same main primitives. ...
This research aims to reduce the cost of retrieving external data for smart contracts from multiple sources while ensuring that the authenticity of the data is publicly verifiable. Two factors influence the total cost. The first is the size of the data, which determines the cost of transmitting the data to the blockchain and storing it, while the second factor is the cost of verifying the authenticity. In this work, we focused on the first factor, as transmission and storage of data are among Ethereum's most expensive operations.
We present two oracles for retrieving data from multiple sources, which we believe to be the first to focus on the multi-source scenario. The oracles both lower the cost of retrieving external data by compressing the proofs of the data's authenticity using aggregate signatures. Even though the oracles achieve the same goal, they are based on different primitives. The first uses bilinear pairings and produces an aggregate signature of constant size, regardless of the number of data sources that are involved. The second is based on the more standard assumption of trapdoor permutations. However, the aggregate signature grows slightly with the number of signers, and the oracle must interact with the data sources sequentially. We confirm the feasibility of our work by implementing and practically evaluating the two oracles in the Solidity programming language. Our experiments show that both oracles expend less gas than non-aggregating oracles based on the same main primitives. ...
Smart contracts are applications that are deployed and executed on a blockchain's decentralised infrastructure. Many smart contract applications rely on data that resides outside the blockchain. However, while traditional web applications can communicate with trustworthy data sources directly through the Internet, this is not possible for smart contracts because their execution must be deterministic. Bringing external data into the blockchain has been a topic of research since the first introduction of Ethereum, and a system that can provide this data to smart contracts is called an oracle. The primary requirement in designing oracles is that the authenticity of the data must be publicly verifiable, which can be achieved through signatures. However, transmitting data to the blockchain and performing the verification is costly, especially if applications require data from multiple sources as, in that case, current approaches would need to retrieve the data from each source separately.
This research aims to reduce the cost of retrieving external data for smart contracts from multiple sources while ensuring that the authenticity of the data is publicly verifiable. Two factors influence the total cost. The first is the size of the data, which determines the cost of transmitting the data to the blockchain and storing it, while the second factor is the cost of verifying the authenticity. In this work, we focused on the first factor, as transmission and storage of data are among Ethereum's most expensive operations.
We present two oracles for retrieving data from multiple sources, which we believe to be the first to focus on the multi-source scenario. The oracles both lower the cost of retrieving external data by compressing the proofs of the data's authenticity using aggregate signatures. Even though the oracles achieve the same goal, they are based on different primitives. The first uses bilinear pairings and produces an aggregate signature of constant size, regardless of the number of data sources that are involved. The second is based on the more standard assumption of trapdoor permutations. However, the aggregate signature grows slightly with the number of signers, and the oracle must interact with the data sources sequentially. We confirm the feasibility of our work by implementing and practically evaluating the two oracles in the Solidity programming language. Our experiments show that both oracles expend less gas than non-aggregating oracles based on the same main primitives.
This research aims to reduce the cost of retrieving external data for smart contracts from multiple sources while ensuring that the authenticity of the data is publicly verifiable. Two factors influence the total cost. The first is the size of the data, which determines the cost of transmitting the data to the blockchain and storing it, while the second factor is the cost of verifying the authenticity. In this work, we focused on the first factor, as transmission and storage of data are among Ethereum's most expensive operations.
We present two oracles for retrieving data from multiple sources, which we believe to be the first to focus on the multi-source scenario. The oracles both lower the cost of retrieving external data by compressing the proofs of the data's authenticity using aggregate signatures. Even though the oracles achieve the same goal, they are based on different primitives. The first uses bilinear pairings and produces an aggregate signature of constant size, regardless of the number of data sources that are involved. The second is based on the more standard assumption of trapdoor permutations. However, the aggregate signature grows slightly with the number of signers, and the oracle must interact with the data sources sequentially. We confirm the feasibility of our work by implementing and practically evaluating the two oracles in the Solidity programming language. Our experiments show that both oracles expend less gas than non-aggregating oracles based on the same main primitives.
D4: Distributed Direct Digital Democracy
A Remote Electronic Voting Protocol
Recently we have been witnesses to a string of controversial elections: the 2016 US Presidential election, the 2016 Brexit referendum, the 2018 Russian presidential election, the 2018 Zimbabwe elections. The controversies surrounding elections are seemingly endless.
Why are these examples relevant? In the 21st century, we are still conducting most of our voting with paper and pencil. Electronic voting methods could resolve much of the controversies and difficulties regarding conventional elections. It would eliminate the uncertainty of counting and be directly verifiable by anyone, not just by a limited number of officials. Electronic voting also has the benefit of being easier to set up and run periodically, which could be implemented to increase the participation of the population further.
This work focuses on how to utilise blockchain in an electronic voting scheme. The blockchain is perfect for voting application for two crucial aspects. First and foremost, due to its inherent public nature, everyone can verify the facts on the blockchain. Verifiability should be a critical requirement for any modern voting system. Secondly, the consensus mechanism allows anyone to participate in the validation and recording of the election process. Furthermore, being distributed, no single entity has full control over the infrastructure.
In the context of voting, verifiability is as valuable as privacy. If the body of literature indicates that verifiability is an inherent property of the blockchain, this is not true for privacy. We propose a scheme that satisfies the strong privacy requirement of receipt-freeness. Validation has shown that the scheme is suitable for large-scale elections and that it performs well on consumer grade hardware. ...
Why are these examples relevant? In the 21st century, we are still conducting most of our voting with paper and pencil. Electronic voting methods could resolve much of the controversies and difficulties regarding conventional elections. It would eliminate the uncertainty of counting and be directly verifiable by anyone, not just by a limited number of officials. Electronic voting also has the benefit of being easier to set up and run periodically, which could be implemented to increase the participation of the population further.
This work focuses on how to utilise blockchain in an electronic voting scheme. The blockchain is perfect for voting application for two crucial aspects. First and foremost, due to its inherent public nature, everyone can verify the facts on the blockchain. Verifiability should be a critical requirement for any modern voting system. Secondly, the consensus mechanism allows anyone to participate in the validation and recording of the election process. Furthermore, being distributed, no single entity has full control over the infrastructure.
In the context of voting, verifiability is as valuable as privacy. If the body of literature indicates that verifiability is an inherent property of the blockchain, this is not true for privacy. We propose a scheme that satisfies the strong privacy requirement of receipt-freeness. Validation has shown that the scheme is suitable for large-scale elections and that it performs well on consumer grade hardware. ...
Recently we have been witnesses to a string of controversial elections: the 2016 US Presidential election, the 2016 Brexit referendum, the 2018 Russian presidential election, the 2018 Zimbabwe elections. The controversies surrounding elections are seemingly endless.
Why are these examples relevant? In the 21st century, we are still conducting most of our voting with paper and pencil. Electronic voting methods could resolve much of the controversies and difficulties regarding conventional elections. It would eliminate the uncertainty of counting and be directly verifiable by anyone, not just by a limited number of officials. Electronic voting also has the benefit of being easier to set up and run periodically, which could be implemented to increase the participation of the population further.
This work focuses on how to utilise blockchain in an electronic voting scheme. The blockchain is perfect for voting application for two crucial aspects. First and foremost, due to its inherent public nature, everyone can verify the facts on the blockchain. Verifiability should be a critical requirement for any modern voting system. Secondly, the consensus mechanism allows anyone to participate in the validation and recording of the election process. Furthermore, being distributed, no single entity has full control over the infrastructure.
In the context of voting, verifiability is as valuable as privacy. If the body of literature indicates that verifiability is an inherent property of the blockchain, this is not true for privacy. We propose a scheme that satisfies the strong privacy requirement of receipt-freeness. Validation has shown that the scheme is suitable for large-scale elections and that it performs well on consumer grade hardware.
Why are these examples relevant? In the 21st century, we are still conducting most of our voting with paper and pencil. Electronic voting methods could resolve much of the controversies and difficulties regarding conventional elections. It would eliminate the uncertainty of counting and be directly verifiable by anyone, not just by a limited number of officials. Electronic voting also has the benefit of being easier to set up and run periodically, which could be implemented to increase the participation of the population further.
This work focuses on how to utilise blockchain in an electronic voting scheme. The blockchain is perfect for voting application for two crucial aspects. First and foremost, due to its inherent public nature, everyone can verify the facts on the blockchain. Verifiability should be a critical requirement for any modern voting system. Secondly, the consensus mechanism allows anyone to participate in the validation and recording of the election process. Furthermore, being distributed, no single entity has full control over the infrastructure.
In the context of voting, verifiability is as valuable as privacy. If the body of literature indicates that verifiability is an inherent property of the blockchain, this is not true for privacy. We propose a scheme that satisfies the strong privacy requirement of receipt-freeness. Validation has shown that the scheme is suitable for large-scale elections and that it performs well on consumer grade hardware.