The Internet Computer is the world’s first blockchain that runs at web speed and can increase its capacity without bound. Like the Internet (which is composed of many machines adhering to TCP/IP protocol) and blockchain protocols (such as Bitcoin and Ethereum).
You can learn more about the Internet Computer’s Protocol, features, and designs here, here are some helpful resources:
Protocol Documentation:
Engineering
You can observe the state of the Internet Computer’s infrastructure (Nodes, data centers, subnets) and traditional blockchain metrics (blocks/second, Token Supply, etc)
To interact with the community, check out the developer forum: https://forum.dfinity.org/
This repo contains many different pieces (including testing and other infrastructure components), but the most important one is the source code for the Rust implementation of the "replica" (read: "client" in some blockchains) that is compiled and run by the machines that together make up the Internet Computer.
The DFINITY Foundation is a Swiss not-for-profit organization based in Zurich, Switzerland, which oversees research centers in Palo Alto, San Francisco, and Zurich. Its goal is to further the design, development, and adoption of the Internet Computer Protocol.
-
If you are an app developer, and your intent is to build apps so you want a local Internet Computer replica in your machine to deploy to, you are better off using the Canister SDK written by the DFINITY Foundation. It is optimized for this and much more lightweight (less than 2 minutes to get started). It will build and run a local replica and you do not need to get into systems code to run it.
-
If you are a blockchain enthusiast, and your intent is to understand the protocol (not an implementation), you may be better off going to the Consensus protocol and IC Interface Specification. This content (by the DFINITY research team) is tailor made for understanding the protocol and design.
-
If you are a blockchain miner, you should know that the Internet Computer Protocol (while it is a blockchain) does not have the traditional mining or validating you may come to expect from blockchain projects. The Internet Computer Protocol is designed using new and novel cryptography that does not require "mining"… but it does require independent node providers, which may include yourself. You can of course check out the source code in this repo, but a better resource may be this: Internet Computer Wiki - For Node Providers
-
If you are an engineer looking to build a new SDK, oracle, wallet or any part that enables and improves the Internet Computer ecosystem, you should take a look at the Interface Specification which is for low-level interaction with the Internet Computer.
-
If you are a systems engineer, security engineer or cryptographer, and your intent is to see what is going on under the hood by digging through source and building this locally, then you are in the right place.
System requirements
-
x86-64 based system (minimum: 16 GB MEM/SWAP, 100 GB available disk space)
-
Ubuntu 22.04 or newer
For detailed information on building IC-OS images, please refer to the IC-OS README
Alternatively, to build all IC-OS images using a simple, containerized environment, run:
$ ./ci/container/build-ic.sh -i
To build only the binaries and canisters, use the -b
and/or -c
flags:
$ ./ci/container/build-ic.sh -b -c
All built artifacts will be located in the top-level artifacts/ directory.
Each release proposal includes instructions on how to verify the build reproducibility of IC-OS update images.
To verify the build reproducibility of a specific IC OS Version Election
proposal, you can just copy the one liner below to a fresh Ubuntu VM 22.04 or higher:
$ sudo apt-get install -y curl && curl --proto '=https' --tlsv1.2 -sSLO https://raw.githubusercontent.com/dfinity/ic/master/ci/tools/repro-check.sh && chmod +x repro-check.sh && ./repro-check.sh -p <proposal>
If you have the repository already cloned, you can just run:
$ ./ci/tools/repro-check.sh -c <git revision>
You can also verify only specific components, by specifying --guestos, --hostos, or --setupos flags:
$ ./ci/tools/repro-check.sh -c <git revision> --guestos
Verifying build reproducibility of GuestOS is sufficient for the Revise Elected GuestOS Versions
NNS proposals.
For the Revise Elected HostOS Versions
NNS proposals, you should verify the build reproducibility of HostOS images.
The default behavior of the script is to verify the build reproducibility of all components.
Thank you for taking the time to learn more about the Internet Computer Protocol. You can contribute to either, but it is important to note that the Internet Computer is governed by a decentralized system called the Network Nervous System (NNS). You can learn more here:
The DFINITY Foundation makes the code of the Internet Computer available to the public.
This is important so that the community can review the code that defines the behaviour of the Internet Computer. Furthermore, the community will be able to build the code and verify that it derives from the same binary image that is referenced in upgrade proposals published via the Network Nervous System (NNS).
All code of the Internet Computer is be licensed under the Apache 2.0 license, except for a few components licensed under the Internet Computer Community Source License and Internet Computer Shared Community Source License which are more restrictive than the Apache 2.0 license to protect the Intellectual Property (IP) of the DFINITY Foundation.
While we adapt our development processes and security reviews for a world of developing with our code in the open, we are not accepting any pull requests at this time. For now, please join our developer community at https://forum.dfinity.org. If you discover any bugs and vulnerabilities, please follow the procedure at https://dfinity.org/vulnerability-disclosure-program/.
To make the mono repository a success, there needs to be some basic rules to make development faster.
-
When adding a new external crate dependency please make sure it is necessary. Check that
-
There isn’t another already imported crate with similar functionality.
-
The crate is well maintained and comes from reputable authors.
-
-
When bumping the semantic version of an external crate, please do it for the whole repository. Avoid importing the same crate with multiple versions.
-
Keep the rust-lang up-to-date for Bazel and Cargo.
-
Use Cargo workspace for inferring external crate versions by adding the new crate to the section
[workspace.dependencies]
of the workspaceCargo.toml
and addingnew-crate = { workspace = true }
to each package-specificCargo.toml
that needs it.