What is Ghostbusters ?

Ghostbusters started as an EOS testnet focused on researching and rehearsing the best practices for running the eosio software in as secure way as possible. It all started because we were worried about the lack of focus regarding infrastructure security.

The Ghostbusters Security Approach was founded by EOS Rio and HKEOS, but has since received contributions from Sw/eden, eosDAC, EOS Tribe, EOS 42, Sheos and many more BPCs in the infrastructure telegram channel. You can see the BPCs active in the network here.

Since this is a community driven project we feel that collaboration between BPCs is very important. This is an educational process and we invite more BPCs to participate in this.

Ghostbusters started as a research environment, not a launch initiative. It quickly attracted the attention from the community and other BPCs who were feeling the same way we do concerning security. Then people started recommending it as a launch approach.

So what is this approach exactly?

You can learn more about it in our Github repo.

It basically combines Keybase for trusted communication and Wireguard for secure node connections. With keybase you can verify your identity, so we guarantee only BPCs can join the group. Also, it has a safe message encryption.

Ideally, no public Internet access should be allowed to BP nodes while still allowing meshing between BP nodes. Hence we propose using secure P2P communication between BP nodes via point-to-point secure tunnels using the open source WireGuard kernel based VPN software. We have also verified that there are no known exploits for Wireguard.

We designed a 4 layer approach to setting up the infrastructure. This has been done in collaboration with infrastructure security expert @jemxpat. It can be seen in the diagram below:

• 1st Layer: Producing nodes - These communicate using Wireguard.
• 2nd Layer: Full nodes to relay blocks, connected to the producing nodes and to other BPs via Wireguard.
• 3rd Layer: API layer where Proxy Servers (web firewalls) filter requests using Patroneos (released by Block.One). These add an extra layer of protection against malicious and malformed data, as well as against volumetric attacks.
• 4th Layer: Load Balancer incoming api calls are routed to our Layer 3 web firewalls.

Will this method be used at Launch?

We don’t know it yet, the community of BPs is reaching consensus on that, it should be defined pretty soon. Honestly, we just want what it’s best for the eos community. We need to take security serious to have a stable and smooth launch. We are committed to one mainnet.

We will continue to improve the Ghostbusters methods. We hope that these methods and guidelines can be seen as some kind of “best practices” and that they can be used by large parts of the BP community.

Please, note that, regardless of the method used to boot, the launch phases are still the same.

Security and Transparency

Security does not mean lack of transparency. We are constantly trying to be as transparent as possible. Our source code is available on Github and our suggestions regarding infrastructure are constantly being discussed and improved by the community :)