An Un-CertiK Future — Contract Security w/ Distributed Audits using TEEs

Introduction

Recent controversies surrounding centralized and trusted third-party auditors like CertiK have highlighted significant vulnerabilities in the current web3 auditing ecosystem. Allegations of collusion with hackers, insider threats, and failures to pinpoint potential risks have undermined trust in these auditing firms. Incidents such as the $3 million siphoning from Swaprum on Arbitrum underscore the need for a more robust and decentralized approach to smart contract security. This blog post explores a novel solution, deployable on TEN.xyz, using DeCC (decentralized confidential compute) and Trusted Execution Environments (TEE) to perform distributed partial audits, managed by a market-making contract. This ensures robust security, mitigates costs, protects intellectual property during development phases, and eliminates the risks associated with centralized auditors.

Distributed Partial Audit Mechanism

Sample Smart Contract

Let’s consider a simplified token contract for this example:

Step 1: Function Segmentation

The contract is broken down into auditable units:

1. transfer()
2. approve()
3. transferFrom()

Step 2: Market-Making Contract Management

A market-making contract manages the audit process through mechanisms such as auctions, bounties, or requests for tender (RFT). It partitions the smart contract into segments and assigns these partitions to whitelisted auditors through transactions.

Step 3: Secure Enclave Execution

Each segmented unit of the smart contract is audited within a secure enclave. This process involves both automated static analysis and manual review by security experts:

1. Automated Static Analysis: Secure enclaves run automated tools to identify known vulnerabilities and ensure coding best practices.
2. Manual Review: Auditors use encrypted viewing keys to access segmented code from within the secure enclave without data leaks, focusing on complex security and logical issues.

For illustration, let’s focus on the transfer() function. The auditor would:

• Verify balance checks and updates.
• Ensure proper event emission.
• Check for reentrancy vulnerabilities.
• Validate the function against specified invariants.

Audit results are encrypted and submitted via secure transactions, aggregated, and verified within other secure enclaves (nodes) to ensure accuracy and consistency.

Step 4: Distributed Auditor Network

Auditors submit their audit results through the audit-task contract, holding submission rights to a partial-audit NFT assigned via the market-making contract. These results are securely aggregated and verified/scored within a TEE against parameters specified by the submitter. The smart contract automates the process, facilitating trustless delivery versus payment (DvP) settlements or notifications for multi-signature authorizations (in the case of larger bounty events), ensuring fair play for both parties.

Step 5: Privacy and IP Protection

Sensitive parts of the contract remain within the secure enclaves, ensuring that auditors only have access to the necessary information for their specific segment. While the details of this partial-audit NFT are initially kept private, they can be disclosed later with mutual agreement, provided it does not have a negative impact, thereby allowing for learning and reference.

Step 6: Consensus Mechanism

A platform consensus mechanism among the TEEs/EVMs running in secure enclaves ensures the final audit result is reliable, reproducible, validated by multiple parties, and available for persistent attestation.

Step 7: Licensing and Revenue Streams

Audit result holders can license proofs of their prior audits, allowing subsequent dApps and contracts to leverage existing audit components for partial functions or child/delegate contracts. This significantly reduces costs by building on previously validated work. Original auditors earn revenue from these licenses, creating a sustainable and scalable ecosystem. This trustless licensing model enhances web3 efficiency, innovation, and security by encouraging the reuse of proven code*.

*At scale, licensing a function becomes a fraction of the development cost, promoting the use of the most efficient and well-vetted implementations. This natural selection process drives developers to focus on innovating novel functionalities.

Example Workflow

Preparation Phase

1. Dependency Mapping: Identify that transfer() depends on `balanceOf `and `emit Transfer`.
2. Contextual Briefing: Auditors are provided with information about `balanceOf` structure and `Transfer` event.

Audit Phase

1. Partitioning and Transactions: The market-making contract partitions the audit and assigns segments to auditors through transactions.
2. Partial Audits in TEEs: Auditors audit their assigned segments within secure enclaves and submit results via transactions.

Integration Testing Phase

1. Comprehensive Testing: Aggregated results are tested within the secure environment, simulating real-world scenarios to ensure that `transfer()` works correctly with `balanceOf` and `Transfer`.

Aggregation and Consensus Phase

1. Result Aggregation: Audit results from multiple auditors are securely aggregated within TEEs (via EVM) running in enclaves.
2. Final Review: A consensus is reached on the audit findings, ensuring thorough coverage.

Licensing Phase

1. License Proofs: Audit result holders can license proofs of their prior audits.
2. Revenue Emission: Original auditors earn revenue from these licenses as other dApps and contracts build on their audit components or query partial attestation proofs.

Deployment and Monitoring Phase

1. Secure Deployment: Deploy the contract with confidence in its security.
2. Continuous Monitoring: Monitor the contract continuously for any emerging issues.
3. Automatic Decentralized Vulnerability Notifications: Implement a system for real-time, decentralized notifications of vulnerabilities. This system can include both manual submissions via crowd-sourced challenge transactions and automated smoke testing for new audits with potential overlapping contexts. This mechanism detects, verifies, and broadcasts potential issues to stakeholders or contract circuit breakers, without compromising security. This ensures a rapid response to emerging threats and ongoing security for the deployed contract.

Benefits

1. Cost Efficiency: Partial audits are less resource-intensive and can be distributed across many auditors, reducing the overall cost.
2. Enhanced Security: TEEs ensure the audit process is secure from tampering and unauthorized access (both external and internal).
3. IP Protection: Segmentation and secure enclaves protect sensitive parts of the smart contract from being fully exposed, mitigating the risk of IP theft and zero-day exploits at initial deployment.
4. Scalability: A distributed approach can easily scale to handle larger and more complex smart contracts by adding more auditors.
5. Reduced Attack Surface: Hackers would need to compromise multiple secure enclaves in a distributed network, which is significantly more challenging than targeting a single audit point.
6. Economic Incentives: Licensing audit proofs creates a revenue stream for original auditors and reduces costs for subsequent projects leveraging these components.
7. Real-Time Security Updates: The decentralized vulnerability notification system ensures that any emerging threats are quickly detected, verified, and addressed, maintaining the security of the contract post-deployment.

Addressing the Centralized Auditor Controversy

The recent controversies involving centralized auditing firms like CertiK underscore the need for a decentralized approach to smart contract audits. Incidents like the Swaprum and Merlin rug-pulls, where millions were siphoned off despite high-security ratings, reveal critical flaws in relying on a single entity for security assurances. Centralized auditors have been implicated in colluding with hackers and failing to disclose significant vulnerabilities, eroding trust in their reports.

How Our Approach Mitigates These Issues

1. Decentralized Trust Model: By distributing the audit process across multiple auditors managed by a market-making contract, we eliminate the reliance on a single entity. This decentralization reduces the risk of collusion and insider threats.
2. Immutable Audit Records: Audit results are submitted and stored on the blockchain, ensuring transparency and immutability. This creates an auditable trail that can be independently verified.
3. Enhanced Accountability: Audit smoke tests and submissions execute and reside in secure enclaves, ensuring that auditor activities are isolated and protected from external tampering. The consensus mechanism ensures that audit results are reliable and agreed upon by multiple independent parties.
4. Real-Time Monitoring and Continuous Audits: The system supports continuous monitoring and periodic re-audits, allowing for real-time detection and mitigation of emerging vulnerabilities.
5. Community-Driven Audits: The distributed nature of the audit process allows for community participation, where independent auditors can contribute to and verify audit results, further enhancing trust and reliability.

Conclusion

By leveraging TEEs and secure enclaves as provided by TEN, we can create a robust and secure distributed auditing system for smart contracts managed by a market-making contract. This approach not only enhances the security and integrity of the audit process but also offers cost efficiency and IP protection. The additional facet of licensing audit proofs introduces economic incentives for auditors and reduces costs for subsequent projects, fostering a sustainable and collaborative ecosystem. As the controversies surrounding centralized auditors like CertiK have shown, adopting a decentralized approach to auditing is crucial for ensuring the reliability and trustworthiness of smart contracts in the decentralized finance (DeFi) ecosystem.

Alch3mist, (aka Anthony Nixon) is a web3 engineer with a passion for cognitive science, AI, and information theory. Currently contributing to TEN.