Hello community,
In the time since the Nintendo DMCA incident in December, the DFINITY Foundation has been actively reviewing community feedback, engaging in discussions and working sessions with community members, and researching best practices from the broader web3 ecosystem. This exercise has led to the revision of several of DFINITY’s existing roadmap items and the creation of new approaches for handling incidents like this in the future.
The Internet Computer is the first blockchain capable of hosting large amounts of data on the blockchain itself, using the memory of advanced “canister” smart contracts, in a significant leap forward. Another advance is that canister smart contracts can also service HTTP requests, and serve interactive web experiences directly to end-users. Together, this means that multimedia content can now be stored on a blockchain and served directly into web browsers. In the foregoing incident, copyrighted games encoded in WebAssembly were served by smart contracts into web browsers, and Nintendo attempted to take action against the computers they could see serving the content.
The community has discussed at length how such incidents should be handled since several approaches can be taken. A consensus has formed that these issues should be handled by those operating “boundary nodes,” which act as HTTP routers through which the network’s subnet blockchain nodes can be reached. The boundary nodes have several purposes: they are geo-aware and can route incoming requests to the nearest subnet node that hosts the canister involved, they can help load balance query transactions, they can hide the IP addresses of end users from the subnet nodes, they can cache cryptographically verified data in the role of a content distribution network, they can throttle excessive interactions from an outside IP address, and they can help protect subnets from DDoS attacks.
At a high level, the plan is to make boundary node operators responsible for deciding whether to forward requests to specific canister smart contracts. This will enable them to filter access to canisters, for example in response to takedown notices that legally oblige them to stop serving content or face sanctions and fines. Since boundary nodes generally serve specific geographies and jurisdictions, this makes it possible that canisters will be accessible in some places, but not others, depending upon where legal action occurs. Having boundary nodes limit access to canisters, on a case-by-case basis, is seen as superior from a decentralization perspective to having node operators attempting to remove or freeze canisters by submitting proposals to the Network Nervous System (a special DAO that automates the management and governance of the Internet Computer blockchain network by the community).
Each operator of boundary nodes will be responsible for defining their own policy and practices. As a boundary node operator, DFINITY is developing its own policy, which will be made public in the coming days and defines in what circumstances it may decide to refuse to route HTTP requests to a canister on the blockchain. Currently, while subnet blockchain node machines are run by independent node providers from data centers around the world, boundary nodes are run exclusively by the DFINITY Foundation, which has allowed it to help protect the blockchain. This situation will soon change, however.
Essentially, independent parties will be able to operate boundary nodes that run as encrypted virtual machine instances hosted on computers built using AMD’s SEV-SNP (Secure Encrypted Virtualization, with Secure Nested Paging) hardware. The use of SEV-SNP to host boundary nodes has three purposes. Firstly, it will prevent even those that own the hardware, whoever they are, from monitoring the data passing through the nodes. Secondly, it will allow short-lived HTTPS certificate information to be stored, which cannot be seen, before the blockchain gains MPC HTTPS capabilities. Thirdly, it will allow the boundary nodes to create cryptographic attestations that they are running the correct software image, and thus are faithfully implementing the protocol, which they can supply to node machines that are hosting subnet blockchains. Boundary nodes will load configurations that their owners specify externally, including canister smart contracts that should not be routed. It is important to note that this SEV work will also be rolled out to subnet node providers and is currently being discussed in the forum here, with an estimated timeline of end of Q2 2022.
At this time, the only way that a node provider can remove a canister from the network, for example in order to comply with a legal notice, is to submit a proposal to the Network Nervous System (NNS) to remove the canister, which will be executed automatically by the network if it is adopted. If their proposal is rejected, their only remaining option may be to take their equipment offline. Even if their proposal is successful, the proper purpose of this proposal type is actually to provide a last line of defense that allows a malicious canister seriously impacting network performance or security to be dealt with. The goal of allowing boundary nodes to decide not to route HTTP requests to specific canisters is to shift decision making to the individual boundary node providers and have them decide what content they should be serving.
Work on several other enhancements is underway, including canister sandboxing, which will eliminate the need for removing or suspending canisters hosted by the blockchain for security purposes. The timeline for these items is estimated by end of March 2022. As a short-term measure, based on community feedback, the DFINITY Foundation plans to propose an update that would change the voting threshold required for proposals of this type to pass to 80%.
We are very pleased with the path forward described and feel it reflects both the concerns and innovations brought forth by the community. We thank you all again for the productive discussion on this topic over the last month, and we have learned a lot from the community, as always. Please stay tuned for updates related to these workstreams in the coming weeks.