Â
Â
Â
​Introduction, some common terms
The Proof of Decentralization (PoD) initiative aims to validate Decentralized Social’s (DESO) ability to operate as a fully decentralized network. Â
Previously, DESO has been reliant upon a limited number of centralized “trusted block producers†(TBTs) to mint new blocks. In 2024 Proof of Stake (POS) validators were added to the node network, but the question continues to be asked – "is it really decentralizedâ€? Â
SafetyNet (https://safetynet.social/u/SafetyNet) is leading a community-driven experiment to prove DESO can operate independently. Â
If successful, this will silence sceptics, strengthen trust in DESO, and showcase its decentralized power. Â
We need you! #WeAreAllDeso – and we build it together!Â
- A key feature of blockchain is decentralization, which means there is no central server or controlling-authority.Â
- Servers making up the ecosystem are called nodes and are linked to each other instead of being reliant on one central server- forming a distributed  peer-to-peer network.Â
- The blockchain is available and stored on each node. In other words, the information is distributed throughout the network instead of being copied. (SafetyNet nodes are all using full blocksync mode, having the full history of deso blockchain)Â
- The peer-to-peer network and decentralization are the powerful features of blockchain and provide security and trust in this system. (You’ll have to hack 51% of the systems to gain control)Â
- Deso Architecture:Â
Â
Proof of Decentralization Experiment
SafetyNet is proposing the following experiment to prove the DeSo blockchain can run without the DeSo core nodes (deso.org or deso.com), hence a clear proof of decentralization.Â
The idea is this:Â
- Connect 3 fully synced (so having full fire hose of blockchain content) DeSo nodes only to each other by using appropriate backend and frontend configuration. All other peer traffic is blocked.Â
- The three are validators rotating as leader in the Proof of Stake mechanism built into deso, minting new blocks and validating those.
- Use independent identity service for signing transactions - configure identity.safetynet.social for user authentication, login and transaction signing for frontends carrying out the experiment.Â
- Obviously SafetyNet users contributing to the experiment will initially have to sign in using their seed phrase to this identity service. BTW: that experiment with our own identity service we already executed earlier and worked great.
- Execute common DeSo transactions to prove independent functionality of:Â
- Create new accountÂ
- PostÂ
- Repost/Quote repostÂ
- React to a post (like)
- CommentÂ
- Diamond a post
- Mint an NFTÂ
- Searching a user
- Aob
- Monitor sync state between the three nodes in the experiment – it is essential that new blocks are mined and synchronized between these nodes to validate the experiment.Â
Â
Technical Instructions for ExperimentÂ
- The database of the isolated nodes is backed up, as to keep state of the block chain safe for recovery after the experiment (as a full resync takes two/three days, which is a fallback if restore fails to bring nodes back to fully operational state)Â
- Isolate network by firewall Â
- Client computers outside the server network need browser access (HTTP/HTTPS), while the SafetyNet Ubuntu servers itself are isolated and restricted to only communicate with the three specified IP addresses (159.69.139.36, 162.55.92.47, and 194.233.74.138), the configuration needs to handleÂ
- Server-to-Server Restriction: Limit the server’s traffic to only the three IP addresses.Â
- Client Accessibility: Allow unrestricted HTTP/HTTPS access for browser clients from the outside.Â
- See appendix for details how to do so via script/iptables on each of the serversÂ
Â
NOTE:Â
GIVEN THIS ISOLATION broken images and videos WILL OCCUR (as images.deso.com and media.deso.com will be gone. Â
Also some fonts used from fontawesome might give some display issues. Â
Configure frontend app to make use of identity.safetynet.social and validatorÂ
export const environment = { Â production: true, Â uploadImageHostname: 'node.safetynetvalidator.nl', Â verificationEndpointHostname: 'https://node.safetynetvalidator.nl', Â uploadVideoHostname: 'node.safetynetvalidator.nl', Â identityURL: 'https://identity.safetynet.social', Â supportEmail: 'support@safetynet.social', Â dd: { Â Â Â apiKey: 'DCEB26AC8BF47F1D7B4D87440EDCA6', Â Â Â jsPath: 'https://safetynetvalidator.nl/tags.js', Â Â Â ajaxListenerPath: ' safetynetvalidator.nl/api', Â Â Â endpoint: ' https://safetynetvalidator.nl/js', Â }, Â amplitude: { Â Â Â key: '', Â Â Â domain: '', Â }, Â node: { Â Â Â id: 31, Â Â Â name: 'SafetyNet', Â Â Â url: 'https://safetynet.social', Â Â Â logoAssetDir: '/assets/deso/', Â }, Â heroswapURL: 'https://heroswap.com', Â heroswapAffiliateName: 'SafetyNetValidator', };
Configure backend with these lines in EnvironmentÂ
 # A comma-separated list of ip:port addresses that we should listen on. # These will take priority over addresses discovered by network # interfaces. EXTERNAL_IPS=159.69.139.36, 162.55.92.47, 194.233.74.138  # A comma-separated list of ip:port addresses that we should connect to on startup. # If this argument is specified, we don't connect to any other peers. This is useful # if you want to debug your node sync without worrying about external factors. CONNECT_IPS=159.69.139.36, 162.55.92.47, 194.233.74.138
Â
Â
Â
Â
APPENDIX ISOLATE NETWORKÂ
client computers outside the server network need browser access (HTTP/HTTPS), while the Ubuntu server itself is isolated and restricted to only communicate with the three specified IP addresses (159.69.139.36, 162.55.92.47, and 194.233.74.138), the configuration needs to handle:Â
- Server-to-Server Restriction: Limit the server’s traffic to only the three IP addresses.Â
- Client Accessibility: Allow unrestricted HTTP/HTTPS access to the clients from the outside.Â
Here’s the setup to achieve this:Â
Â
Step 1: Flush Existing RulesÂ
Clear any existing rules to avoid conflicts:Â
sudo iptables -FÂ
sudo iptables -XÂ
Â
Step 2: Set Default Policies to DropÂ
Set default policies to drop all traffic:Â
sudo iptables -P INPUT DROPÂ
sudo iptables -P OUTPUT DROPÂ
sudo iptables -P FORWARD DROPÂ
Â
Step 3: Allow Loopback TrafficÂ
Enable loopback traffic for internal processes:Â
sudo iptables -A INPUT -i lo -j ACCEPTÂ
sudo iptables -A OUTPUT -o lo -j ACCEPTÂ
Â
Step 4: Allow Traffic to/from the Three IPsÂ
Restrict server traffic to only the specified IP addresses:Â
# Allow incoming traffic from the allowed IPsÂ
sudo iptables -A INPUT -s 159.69.139.36 -j ACCEPTÂ
sudo iptables -A INPUT -s 162.55.92.47 -j ACCEPTÂ
sudo iptables -A INPUT -s 194.233.74.138 -j ACCEPTÂ
Â
# Allow outgoing traffic to the allowed IPsÂ
sudo iptables -A OUTPUT -d 159.69.139.36 -j ACCEPTÂ
sudo iptables -A OUTPUT -d 162.55.92.47 -j ACCEPTÂ
sudo iptables -A OUTPUT -d 194.233.74.138 -j ACCEPTÂ
Â
Step 5: Allow Established and Related ConnectionsÂ
Enable established connections to ensure smooth communication:Â
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTÂ
sudo iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPTÂ
Â
Step 6: Enable Client Browser Access (HTTP/HTTPS)Â
Allow client computers to access the server for HTTP/HTTPS traffic:Â
1. Allow Incoming HTTP/HTTPS Traffic:Â
Â
# Allow incoming HTTP traffic (port 80)Â
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPTÂ
Â
# Allow incoming HTTPS traffic (port 443)Â
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPTÂ
2. Allow Outgoing HTTP/HTTPS Responses:Â
Â
# Allow outgoing HTTP traffic (port 80)Â
sudo iptables -A OUTPUT -p tcp --sport 80 -j ACCEPTÂ
Â
# Allow outgoing HTTPS traffic (port 443)Â
sudo iptables -A OUTPUT -p tcp --sport 443 -j ACCEPTÂ
Â
Step 7: Save and Persist the RulesÂ
Save the rules to make them persistent across reboots:Â
- Install iptables-persistent if not already installed:Â
Â
sudo apt-get install iptables-persistentÂ
- Save the rules:Â
Â
sudo netfilter-persistent saveÂ
sudo netfilter-persistent reloadÂ
Â
Step 8: Verify ConfigurationÂ
- Check the iptables rules:Â
sudo iptables -L -vÂ
Confirm rules for:Â
- Only allowing traffic between the server and the three IP addresses.Â
- HTTP/HTTPS access for external clients.Â
- Test:Â
- From a client computer, access the server in a browser:Â
Â
http://<your-server-ip>Â
orÂ
Â
https://<your-server-ip>Â
- Confirm that server traffic outside the three IPs is blocked:Â
Â
Â
curl http://deso.comÂ
It should fail if deso.com is not one of the allowed IPs.Â
Â
Key NotesÂ
- HTTP/HTTPS for Clients: This rule allows all external clients to access the server over HTTP/HTTPS.Â
- Server Communication: The server can only communicate with the three specified IP addresses.Â
- DNS Traffic: If the server itself requires DNS resolution (for example, for connecting to the allowed IPs by domain), allow DNS traffic as well:Â
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPTÂ
sudo iptables -A INPUT -p udp --sport 53 -j ACCEPTÂ
With this setup, your server is isolated for outbound communication but accessible for external clients via HTTP/HTTPS.Â
Here's a Bash script that:Â
- Saves the current iptables configuration to a file.Â
- Applies the desired iptables setup to restrict traffic to the three specified IPs (159.69.139.36, 162.55.92.47, and 194.233.74.138) while allowing HTTP/HTTPS access for external clients.Â
- Restores the original iptables configuration from the saved file.Â
Â
Script: manage_iptables.shÂ
#!/bin/bashÂ
Â
# Paths for saving and restoring iptables rulesÂ
SAVED_RULES="/tmp/iptables_saved.rules"Â
RESTORE_RULES="/tmp/iptables_restored.rules"Â
Â
# Define desired IPsÂ
ALLOWED_IPS=("159.69.139.36" "162.55.92.47" "194.233.74.138")Â
Â
# Save the current iptables rulesÂ
save_rules() {Â
   echo "Saving current iptables rules..."Â
   sudo iptables-save > "$SAVED_RULES"Â
   echo "Rules saved to $SAVED_RULES"Â
}Â
Â
# Restore iptables rules from saved fileÂ
restore_rules() {Â
   if [ -f "$SAVED_RULES" ]; thenÂ
       echo "Restoring iptables rules..."Â
       sudo iptables-restore < "$SAVED_RULES"Â
       echo "Rules restored from $SAVED_RULES"Â
   elseÂ
       echo "No saved rules found at $SAVED_RULES. Cannot restore."Â
       exit 1Â
   fiÂ
}Â
Â
# Apply desired iptables setupÂ
apply_desired_setup() {Â
   echo "Applying desired iptables setup..."Â
   # Flush existing rulesÂ
   sudo iptables -FÂ
   sudo iptables -XÂ
Â
   # Default policies to drop all trafficÂ
   sudo iptables -P INPUT DROPÂ
   sudo iptables -P OUTPUT DROPÂ
   sudo iptables -P FORWARD DROPÂ
Â
   # Allow loopback trafficÂ
   sudo iptables -A INPUT -i lo -j ACCEPTÂ
   sudo iptables -A OUTPUT -o lo -j ACCEPTÂ
Â
   # Allow traffic to/from the specified IPsÂ
   for IP in "${ALLOWED_IPS[@]}"; doÂ
       sudo iptables -A INPUT -s "$IP" -j ACCEPTÂ
       sudo iptables -A OUTPUT -d "$IP" -j ACCEPTÂ
   doneÂ
Â
   # Allow established and related trafficÂ
   sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPTÂ
   sudo iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPTÂ
Â
   # Allow HTTP/HTTPS traffic for external clientsÂ
   sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPTÂ
   sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPTÂ
   sudo iptables -A OUTPUT -p tcp --sport 80 -j ACCEPTÂ
   sudo iptables -A OUTPUT -p tcp --sport 443 -j ACCEPTÂ
Â
   # Optional: Allow DNS resolution if neededÂ
   sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPTÂ
   sudo iptables -A INPUT -p udp --sport 53 -j ACCEPTÂ
   sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPTÂ
   sudo iptables -A INPUT -p tcp --sport 53 -j ACCEPTÂ
Â
   echo "Desired iptables setup applied."Â
}Â
Â
# Menu for managing iptablesÂ
case "$1" inÂ
   save)Â
       save_rulesÂ
       ;;Â
   restore)Â
       restore_rulesÂ
       ;;Â
   apply)Â
       apply_desired_setupÂ
       ;;Â
   *)Â
       echo "Usage: $0 {save|restore|apply}"Â
       echo " save   - Save current iptables rules"Â
       echo " restore - Restore iptables rules from saved file"Â
       echo " apply  - Apply desired iptables setup"Â
       exit 1Â
       ;;Â
esacÂ
Â
Usage InstructionsÂ
- Save the script: Save the script as manage_iptables.sh and make it executable:Â
chmod +x manage_iptables.shÂ
- Save the current iptables rules:Â
./manage_iptables.sh saveÂ
- Apply the desired setup:Â
./manage_iptables.sh applyÂ
- Restore the saved iptables rules:Â
Â
./manage_iptables.sh restoreÂ
Â
NotesÂ
- Requirements: The script requires sudo privileges to execute iptables commands.Â
- Persistence: To make the rules persist across reboots, use iptables-persistent:Â
sudo apt-get install iptables-persistentÂ
sudo netfilter-persistent saveÂ
- Validation: Use sudo iptables -L -v to validate the current rules after applying or restoring.Â
This script makes it easy to toggle between the current and desired iptables configurations.Â
Â
Â
Â