The European Union's Data Act seeks to give people more control over what can be done with their data, particularly in relation to IoT.
By Hein Dauven | Mar 28, 2023 - Rotterdam
The European Union's Data Act seeks to give people more control over what can be done with their data, particularly in relation to IoT. However, the legislation has been criticized for its "one size fits all" approach, with some arguing that it lacks clarity. One of the criticisms is that, once again, the technical side was not involved in the creation of the legislation, and this lack of knowledge is exactly why it lacks any clarity. This article will explore the potential introduction of a kill switch and pause functionality in smart contracts proposed in the act, analyzing how these features can both protect and impede innovation, and whether alternative solutions might be more appropriate.
The Rationale for a kill switch and pausing
The EU's desire for a kill switch and pausing functionality stems from the need to protect users from potential risks associated with smart contracts, particularly in the context of the Internet of Things (IoT). While the Data Act does not explicitly mention blockchain-based smart contracts, the lack of clarity in the legislation has raised concerns for those in the blockchain industry.
Alternatives to the proposed functionalities
Despite the potential benefits, critics argue that kill switches and pausing functionality may introduce friction and limit the advantages of smart contracts. Alternatives could include greater reliance on social consensus, with control over smart contracts distributed among a variety of stakeholders. This approach could enhance trust while maintaining the decentralized nature of blockchain technology.
Who is in control?
The question of who should have control over kill switches and pausing functionality raises concerns about trust and centralization. Three main options exist: single user control, multi-signature (multi-sig) control, and decentralized autonomous organizations (DAOs). Each option has its own implications for trust and the speed at which the kill switch or pause can be executed.
Single user control: In this scenario, one individual or entity has the authority to activate the kill switch or pause functionality of the smart contract. While this option allows for the fastest response time in case of an emergency, it centralizes power and control, potentially raising concerns about trust and vulnerability to malicious actions/actors. Moreover, the single user may not have the necessary expertise to make the best decision in every situation, which could lead to suboptimal outcomes. There’s also the risk of loss of the private key attached to this single user, which could make executing the functions impossible in the future.
Multi-signature (multi-sig) control: Multi-sig control requires multiple users to authorize the activation of a kill switch or pause functionality, usually through a predefined threshold of signatures, such as a 3-of-5 or 4-of-7 scheme where a majority of participants must approve actions. This approach distributes decision-making power and reduces the risk of misuse or errors. Trust is enhanced as no single user can unilaterally control the system. However, the speed of execution may be slower compared to single user control, as the approval process involves multiple parties and potential delays in coordinating their actions. In case of one of the users losing their keys, it’s still possible to get to a predefined threshold or to swap out users if need be if their key is lost for example, providing a layer of redundancy.
Each option for controlling kill switches and pausing functionality in smart contracts has its own trade-offs in terms of trust and speed. Striking the right balance between these factors is crucial for ensuring that kill switches and pause functions can protect users without stifling innovation or compromising the benefits of decentralization.
Social consensus and its role in trust
Social consensus, a concept rooted in the idea of collective decision-making, involves the participation of various stakeholders in reaching an agreement on a specific issue. Social consensus can facilitate a democratic and transparent approach to managing key features such as the proposed kill switch and pause functionality, in favor of outsourcing it to a new bureaucratic entity with sweeping control over any deployed smart contract.
Social consensus can play a crucial role in building trust in systems with kill switches and pause functionality, particularly in the context of the Data Act and its goals. Distributing control over these features among various stakeholders can ensure that decisions are made in a more decentralized manner and transparently, fostering trust in both the regulatory benefits put forth by the Data Act and the decentralized nature of the blockchain ecosystem.
The Data Act aims to provide a framework that both safeguards users from potential data risks while ideally also preserving the innovative potential of smart contracts and other digital technologies. By incorporating social consensus into the decision-making process for kill switches and pause functionality, the EU can strike a balance between protecting users and preventing undue centralization of power that goes against the core ethos of the crypto community.
In a smart contract backed by a DAO/social consensus, the participants have a vested interest in ensuring the contract's integrity and security. Should the smart contract be hacked, contain a bug, or be used in a fraudulent way, the stakeholders can collectively decide to pause or activate the kill switch to protect their interests and prevent further damage. This approach aligns with the incentives of the participants, as they all share the responsibility of maintaining the contract's integrity and value.
Social consensus empowers the participants in a smart contract to act in their collective best interest, providing a robust safeguard against potential threats. It is an approach that would not compromise on the values espoused by the crypto community, while at the same time getting to the heart of the issue that the EU wants to solve with a kill switch and pause functionality. Good faith actors would choose to comply and create a vibrant and well informed community that can harbor the security of its own protocols.
Legal entities and liability
Involving legal entities in multi-sig or DAO arrangements can provide a layer of accountability and liability protection, helping to maintain trust in the system while still offering the benefits of decentralization. Within the context of the Data Act, companies can leverage the concept of a DAO or multi-sig to appoint the appropriate individuals within their organization, as well as external auditors, to oversee the kill switch or pause functionality of smart contracts.
For instance, a company could create a multi-sig arrangement where key personnel, such as executives or board members, along with external auditors or legal representatives, are designated as signatories with the authority to activate the kill switch or pause a smart contract. These individuals should be known and legally accountable for their actions, ensuring compliance with regulations and fostering trust in the system.
Another approach involves forming a DAO as a legal entity, making it liable for the functioning of a smart contract. This could be achieved by registering the DAO as a legal entity, such as a corporation or a limited liability company, subject to the jurisdiction and regulatory requirements where it operates. By doing so, the DAO would be held accountable for its actions, and the participants would be required to adhere to relevant regulations and legal obligations.
In either case, the involvement of legal entities in the governance of smart contracts under the Data Act can help strike a balance between the decentralized nature of blockchain technology and the need for regulatory compliance and accountability. By combining the benefits of decentralization with a framework of legal responsibility, companies can foster trust in their smart contract systems while ensuring adherence to the Data Act's requirements and protecting users from potential risks.
Implications for composability
Composability refers to the ability of smart contracts to seamlessly interact with one another, building upon each other's functionality to create more complex applications and systems. This property allows developers to create modular and reusable components that can be combined in various ways.
Introducing a kill switch or pausing function can pose risks to the composability of smart contracts, potentially leading to a cascading effect of affected contracts. When a smart contract is paused or terminated using a kill switch, it may disrupt the normal functioning of other contracts that depend on it, causing a chain reaction of disruptions throughout the interconnected system of smart contracts.
For example, consider a decentralized finance (DeFi) platform where multiple smart contracts are designed to work together, such as lending protocols, decentralized exchanges, and stablecoins. If a critical smart contract within this ecosystem is paused or terminated, it could prevent other contracts from executing their functions, leading to a breakdown in the entire platform. Users may be unable to access their funds or execute transactions, resulting not only in a breach of trust but potentially also a loss of funds. Something the Data Act is supposed to prevent, not cause.
Understanding these risks and their potential impact on innovation is crucial for striking the right balance between security and flexibility. While the implementation of a kill switch or pausing function may provide valuable safeguards against hacks, fraud, and unforeseen consequences, it is essential to consider the potential disruptions and unintended consequences that these mechanisms might introduce to the composability of smart contracts.
In order to minimize the risks associated with kill switches and pausing functions, regulators and developers must explore alternative solutions or implement safeguards that minimize the potential cascading effects while still providing a level of protection and control that could meet the regulatory goals of the Data Act.
Mutability versus immutability in the Data Act
The Data Act's impact on mutability and immutability of data raises important questions about the extent to which smart contracts can be modified. Striking the right balance between adaptability and security is essential for future innovation.
In the context of smart contracts, the immutability of the code and the tamper-proofnature of the transaction history are key features that ensure trust and security within the blockchain ecosystem. The code of a smart contract cannot be changed after it has been deployed, and the transaction history remains unalterable. However, smart contracts do carry state, which can be mutable. This means that the current state of a smart contract can be updated or modified, but the history of those changes remains unchangeable.
Although the code of a smart contract is immutable, developers can design contracts with a certain degree of flexibility, allowing for upgrades or modifications to adapt to changing circumstances, add features, to fix potential bugs or vulnerabilities. This can be achieved through mechanisms such as upgradeable contract proxies or contract modules that can be replaced or updated without altering the core contract logic.
In the context of the Data Act, balancing the mutable state of smart contracts and the immutability of their code and transaction history becomes crucial, as the legislation seeks to protect user data and maintain a secure environment. On one hand, allowing for some level of flexibility in the contract state enables developers to respond to unforeseen issues or regulatory requirements, ensuring that smart contracts remain compliant and functional. On the other hand, preserving the immutability of the code and transaction history is essential to maintaining the trust and security that blockchain technology offers.
On-chain and off-chain data
Understanding the distinction between on-chain and off-chain data is vital for implementing the Data Act. This distinction has implications for how data is stored, accessed, and regulated within the blockchain ecosystem and how dApps handle state.
On-chain data refers to information that is stored directly on the blockchain. This includes transaction history, smart contract code, and any other data that is recorded and maintained within the distributed ledger. On-chain data is immutable and transparent, ensuring the security of the blockchain. A contract can change its state, but this state change is recorded as history and observable.
Off-chain data, on the other hand, refers to information that is stored outside of the blockchain. This can include databases, file storage systems like IPFS, or any other external data sources. Off-chain data can be mutable and the change of data can be done in an untraceable way. It allows for greater flexibility and adaptability, which comes with trade-offs in terms of trust and security, as off-chain data is not subject to the same transparency and traceability as on-chain data.
In the context of the Data Act, the distinction between on-chain and off-chain data is crucial, as it has implications for the storage and regulation of sensitive information such as trade secrets. While the Data Act may require certain data to be kept confidential, it is possible for developers to circumvent these requirements by storing sensitive information off-chain. This approach can offer greater control over access to the data and help maintain trade secret protection. However, it also raises questions about the transparency and regulatory compliance of such systems. User data can be tampered with unbeknownst to them and with no verifiable trace.
The role of Zero-Knowledge Proofs and RegDeFi
Zero-knowledge proof enabled and Regulated DeFi infrastructures like Dusk Network can make compliance with the Data Act easier by providing selective disclosure, privacy and visibility. This technology can ensure that off-chain modifications are legitimate while still protecting sensitive data, such as trade secrets.
Dusk Network leverages selective disclosure to minimize the exposure of sensitive information, allowing only authorized parties to access specific data within a smart contract. Through the use of zero-knowledge proofs, Dusk enables trade secrets to remain confidential while still providing the necessary transparency for regulatory compliance. This approach ensures that sensitive information is not unnecessarily exposed, thus reducing the risk of unauthorized access or misuse.
Additionally, Dusk Network's built-for-compliance smart contracts introduce cleaner roles for auditors and other stakeholders, enabling them to selectively view parts of a smart contract that others cannot access. These roles can be, and in Dusk’s XSC standard are, extended to include roles that allow the pausing of smart contract execution.
Furthermore, the use of zero-knowledge proofs and selective disclosure in Dusk Network can help reduce fraud risks associated with smart contracts. By allowing only authorized parties to view and modify specific data, the technology minimizes the potential for tampering, unauthorized access, or manipulation. This ensures the integrity of the smart contracts and enhances the overall security of the blockchain ecosystem.
In summary, Dusk Network can help address the challenges posed by the Data Act by providing selective privacy, visibility, verifiable computation and built-for-compliance smart contracts. These technologies offer a balanced approach to maintaining the confidentiality of trade secrets and enabling auditors to perform their roles effectively while reducing fraud risks and ensuring compliance with regulatory requirements.