We’re working hard to build Gala Film bigger and better every day. Today, we want to share the following critical update for Film Node operators:
Starting on Monday, June 3rd in order to receive Distribution Film Nodes must meet the following requirements;
Node Software version v3.6.6 (or higher)
The following ports must be exposed: 4002, 9096, 5443
Each node must have it’s own Public IP Address
System:
Windows, Mac, or Linux (64-bit)
4GB RAM
2 or more CPU Cores
60GB free storage space
A stable internet connection
This includes any Nodes currently running and any new Nodes that come online. Any nodes that do not satisfy all of these requirements by Monday, June 3rd will not be eligible for Film Rewards Distribution until the requirements are met.
Check Your Node Status
Head over to your Node Dashboard (https://node.gala.com/#/). If your Node is on version v3.6.6 (or higher) and you have a GREEN dot next to your node, the various workloads, and the port status icon next to “Running” – you are all good. No action required!
Please be patient with these steps. These requirements empower your Nodes that are running Gala Film workloads to support the Gala Decentralized Content Delivery Network (dCDN). This is still an experimental, emerging technology that requires thousands of Nodes to talk to each other as well as Gala backend services. All of this network communication taking place means things (like port checking and online status updates) may take longer than expected.
If you are interested in more of the technical details of Nodes, please check out the FAQs at the end.
If the Dot Under ‘Node’ Is Orange
Check the following;
Each node runs on its own unique Public IP Address This will generally be an issue if you run multiple nodes from your home network. If your Node runs on a VPS or if you run a single Node at home you likely do not have to worry about this at all.
Your nodes meet the minimum system requirements. With more workloads going through the node ecosystem, if your node does not meet the requirements it may frequently fall offline.
Windows, Mac, or Linux (64-bit)
4GB RAM
2 or more CPU Cores
60GB free storage space
A stable internet connection
You can find multiple guides for setting up, managing and updating your node Software on the Gala Node Support Page:
Issue Fix #1 – Is your node version v3.6.6 (or higher)?
If your node is currently under version v3.6.6, you will need to update your node. This can only be done via your system, and NOT through the Node Dashboard.
You can find guides for updating your node Software on the Gala Node Support Page.
If you find an ORANGE Status on the Node Management Dashboard, hover over the icon to highlight the issue you need to resolve to get your node back online.
Gala Nodes require certain ports to be open for your node to run.
Any nodes running at home will likely be behind a firewall as part of your Internet Service Provider. If you’re a Node Operator running through your home connection and need these ports exposed, you will need to set up port forwarding through your ISP.
Any Nodes running on a VPS probably already have these ports exposed.
The following 3 ports all need to be open; 4002, 9096, 5443.
Check your firewall settings to open these ports if needed.
Previously we required Ports 4002, 9096, and 5080. Please note that the third port number requirement has changed and your Film workload will not be able to run without all three ports exposed.
Try using a free port checking tool (like this one: https://portchecker.co/) to verify that the correct ports are exposed.
Once the ports are available, it could take several hours for your node to recognize that the ports are properly exposed.
Issue Fix #3 – Have you restarted your Node?
Once your Node Software is up to date (v3.6.6 or higher) your Film Workload will automatically update itself to the latest version (v4.1.21 as of this article’s publishing). Once your Gala Film Workload has automatically updated, YOU WILL NEED TO RESTART YOUR NODE.
You should see a “Restart Required” message in the Node Management page next to the restart button if your Node requires a restart. This is a Node restart, not a Film Workload restart.
The restart will need to happen AFTER your Film Workload has updated itself to the latest version (v4.1.21 as of this message going out for the first time), if you restart before the update is complete it will need to be restarted again.
Important Notes
It can take a while for your workload to verify that the ports are exposed so please be patient!
Once you see your Film Workload is up and running according to the Node Management page, it may also take some time for your Node Dashboard to show your node online.
FAQs:
Q: Why does each node require its own Public IP address?
A: The core technology that powers the dCDN uses IPFS, which relies on public IP addresses to identify peers. Our IPFS implementation is technically able to perform NAT (thanks to libp2p) however, the dCDN egress doesn’t (yet). So, for now, we rely on a fixed set of ports and a public IP.
Q: Why do we need to expose those ports both inbound and outbound?
A: We require inbound traffic because your Node isn’t just talking to a backend server, it’s actually talking to A BUNCH of other peers (thus, a decentralized system). If your node can’t be reached by its peers, then your Node can’t participate in the network. Also, if a node doesn’t allow inbound traffic then no client can send a request to stream content from that node.
Q: Why are there more requirements for running a Film Workload on a Gala Node than any other Gala Workloads? A: Film Workloads (and Film-Beta Workloads) are the only Gala Node workloads that facilitate and participate in the Gala Decentralized Content Delivery Network (dCDN) at this time.
It’s almost time for an important update to the Gala Node ecosystem that will enhance rewards for the most active operators.
As the Gala ecosystem was building its infrastructure and first proving viability, Founder’s Node operators were rewarded for operation based on their ability to meet the minimum 6-hour uptime requirement during each 24 hour distribution period. This system should be familiar to all Founder’s Node operators today, as it is the system we have used for several years.
In this current system, 1 point is awarded to each Founder’s Node that has met its minimum uptime requirement for the day. Then the $GALA generated for the day is distributed proportionally to the allocation of the points. This straightforward system provides no incentive for Node operators to support the network by operating their Nodes for longer than 6 hours each day.
We’re looking for node operators who support our vision of building the largest decentralized network in the world, so we devised a solution that would a) remove the minimum uptime requirement,and b) reward those who run their Nodes around the clock.
The Long Term Plan
In 2021, it was first announced HERE (and decided through a decentralized governance vote) that the network would eventually shift to such a system. Amid the excitement of opening GalaChain to external development via tools like the GalaChain SDK and the Gala Creator Portal, as well as the web3 buzz surrounding the March 20-21 GalaChain Hackathon GDC competition, we’re thrilled to announce that the time has come.
These updates will go live soon, switching to the new distribution system and rewarding node operators based on a new point system, described in more detail below.
The Point System
The original point system was “pass or fail” with the operator receiving either 0 points for not meeting the requirements or 1 point for meeting the requirements.
The new point system allows operators to earn partial points, creating a more accurate reward structure based on actual operation time.
Every 6 hour period equals 1 point. Therefore the max points for a 24 hour day is 4.
Another way of phrasing this is through the following formula:
Points = (Seconds Online ÷ 3600) x (4 ÷ 24)
While this point structure is changing, the total amount of $GALA available in the daily distribution will not change, except when a dynamic supply event occurs as described in the Gala Ecosystem Blueprint.
The founders distribution still follows the same formula:
Point Value = Distribution $GALA Amount / Total Points
Reward = Points * Point Reward Value
Founder’s Nodes and Common Ground World Nodes
This change will initially only affect the distribution of $GALA from Founder’s Nodes and $DIRT from Common Ground World Nodes.
For Common Ground World Nodes, the 1 $DIRT received per day for an active node will now be the maximum that a Common Ground World Node will generate when active for 24 hours in a day. A Common Ground World Node that is active for 6 hours will receive .25 $DIRT, and so on.
Next Steps
This update is an important step in the process toward making tokenized licenses called Node Workload NFTs, which will allow Node operators to transfer their Node licenses to other users. Shortly after the start of this new distribution structure, we will convert Common Ground World Node licenses to the ecosystem’s first Node Workload NFTs. The tokenization of Founder’s Node licenses will follow shortly after.
Running the Newest Client
With a future update to this system, modifiers will be implemented that reward additional points to operators who run the newest version of the Node client or reduce points for running a deprecated version of the Node client. These details are still being fine tuned and we will share updates as they become available.
Thank you for supporting the decentralized Gala ecosystem, and we look forward to many more years of building and innovating through the power of GalaChain!
Following extensive conversation with the community and having hosted an AMA in the Founders Node Owner channel, the originally posted proposal has been modified in several ways.
Currently, this will apply to all existing referrals, but eventually there will be a point at which they must be “written to chain” via a burn. This will ensure that in the long-term, only those who are active in the ecosystem continue to benefit from the referral system
In the end state, referrals will be temporary unless written to chain by a burn. This means that a web2 user can refer a friend and benefit from that referral, but that it will expire unless they “claim” it via a burn in the social dashboard.
The time to implement the full version of this is 90 days, rather than the initial 7, due to the added lift on engineering and design for the ability to write all referrals to chain.
Rollout will be phased:
Two Weeks: Burn rebates for referrers based on burns on ETH.
One Month: Burn rebates for referrers based on GalaChain.
Two Months: Referral Dashboard v1
Three Months: Referral Dashboard v2 + Write Referrals to Chain
After this phased rollout, non-chain referrals will begin to count-down towards expiration.
The remainder of the proposal remains the same.
The core of this proposal introduces a referral system designed to incentivize ecosystem supporting actions. By engaging in token burn activities, users contribute to the ecosystem’s sustainability and incentivize the long-term Founder’s Node support of the ecosystem. In recognition of the importance of community-driven growth, the proposal outlines that when a user (USER C) initiates a burn, the account that referred USER C (USER B) will receive a reward equivalent to 8% of the burned amount. The account that referred USER B (USER A) will receive the equivalent of 2% of the burned amount. This initiative aims to foster a more engaged and collaborative community, encouraging wider participation in the ecosystem’s development.
This will not impact the Founder’s Node emission rate, but can be looked at as a referral burn rebate for ecosystem supporting actions.
In the event that there is no referring party, then there would be no referral burn rebate.
Example:
User A refers User B.
User B refers User C.
User C initiates a burn of 1000 $GALA
User B receives a mint allowance for 80 $GALA
User A receives a mint allowance for 20 $GALA
Actions which would qualify:
Purchase by burn
Gas fees
Channel establishment fees
Note: All previous referrals would still remain part of this system. If you have referred a user previously and they are a part of your account, then you would still receive the referral bonus based on their gas burning actions.
Key Highlights:
Referral Rewards: The introduction of a referral reward mechanism encourages existing ecosystem participants to bring new users onboard, enhancing the network’s robustness and activity level.
Incentive Structure: Focusing on on-chain actions, excluding bridging activities, ensures the incentive mechanism is transparent and straightforward. This clarity is crucial in maintaining the integrity and purpose of the incentive system.
Implementation Timeline: With a commitment to agility and responsiveness, the proposed system is slated for implementation within 90 days following approval. This rapid deployment timeline underscores the ecosystem’s dedication to innovation and timely enhancement.
Community and Governance Engagement:
Consistent with the ethos of transparency and collective decision-making, this proposal will undergo thorough discussion within the Founder’s Node Operator. There will be at least one AMA on this topic, with extended engagement, to gather feedback ensuring that the proposal is refined and aligned with the community’s vision and needs.
Voting Options:
The voting options are currently as follows, though they may be modified by discussions prior to a governance vote:
Vote Question:
Should the Referral Incentive System be implemented to enhance ecosystem sustainability and community engagement?
Yes: I support the implementation of the Referral Incentive System as proposed, recognizing its potential to enhance ecosystem sustainability and community engagement through incentivized token burns.
No: I do not support the proposal as it stands. I believe that the proposed referral system and token burn incentives may not align with the ecosystem’s long-term growth and engagement goals.
Abstain: I choose to abstain from voting on this proposal. While I acknowledge the importance of community-driven initiatives and ecosystem sustainability, I require more information or am neutral on the impact of the proposed referral incentive system.
This vote will end next Monday, March 18th, 2024 at noon PT.
Conclusion:
This proposal represents a strategic step towards leveraging the Gala Founders Node Ecosystem’s full potential, encouraging active participation, and rewarding contributions that drive the ecosystem forward. Through collaborative efforts and a shared commitment to innovation, the ecosystem can continue to evolve, offering increased value and opportunities for all participants.
In the spirit of fostering innovation and collaboration within the Gala Founders Node Ecosystem, a new proposal is presented for consideration. This proposal is a direct response to the community feedback, emphasizing our collective journey towards enhancing network growth and engagement.
Proposal Overview:
A view of the topic to be discussed below.
The core of this proposal introduces a referral system designed to incentivize ecosystem supporting actions. By engaging in token burn activities, users contribute to the ecosystem’s sustainability and incentivize the long-term Founder’s Node support of the ecosystem. In recognition of the importance of community-driven growth, the proposal outlines a mechanism by which the actions taken by a user can potentially benefit those who brought them into the ecosystem.
Using the flow chart above, USER A refers USER B to the ecosystem, at which point USER B refers USER C.
If the proposal is confirmed by the Founder’s Nodes, when USER C initiates a burn, the account that referred them (USER B) will receive a mint allowance equivalent to 8% of the burned amount. The account that referred USER A will receive the equivalent of 2% of the burned amount. This initiative aims to foster a more engaged and collaborative community, encouraging wider participation in the ecosystem’s development.
This will not impact the Founder’s Node emission rate, but can be looked at as a referral burn rebate for ecosystem supporting actions.
In the event that there is no referring party, then there would be no referral burn rebate.
Example:
User A refers User B. User B refers User C.
User C performs an action which initiates a burn of 1000 $GALA User B receives a mint allowance for 80 $GALA User A receives a mint allowance for 20 $GALA
Actions which would qualify:
Purchase by burn
Gas fees
Channel establishment fees
Note: All previous referrals would still remain part of this system. If you have referred a user previously and they are a part of your account, then you would still receive the referral bonus based on their $GALA burning actions.
Key Highlights:
Referral Rewards: The introduction of a referral reward mechanism encourages existing ecosystem participants to bring new users onboard, enhancing the network’s robustness and activity level.
Incentive Structure: Focusing on on-chain actions, excluding bridging activities, ensures the incentive mechanism is transparent and straightforward. This clarity is crucial in maintaining the integrity and purpose of the incentive system.
Implementation Timeline: With a commitment to agility and responsiveness, the proposed system is slated for implementation within 7 days following approval. This rapid deployment timeline underscores the ecosystem’s dedication to innovation and timely enhancement.
Community and Governance Engagement:
Consistent with the ethos of transparency and collective decision-making, this proposal will undergo thorough discussion within the Founder’s Node Operator. There will be at least one AMA on this topic, with extended engagement, to gather feedback ensuring that the proposal is refined and aligned with the community’s vision and needs.
Voting Options:
The voting options are currently as follows, though they may be modified by discussions prior to a governance vote:
Yes: I support the implementation of the Referral Incentive System as proposed, recognizing its potential to enhance ecosystem sustainability and community engagement through incentivized token burns.
No: I do not support the proposal as it stands. I believe that the proposed referral system and token burn incentives may not align with the ecosystem’s long-term growth and engagement goals.
Abstain: I choose to abstain from voting on this proposal. While I acknowledge the importance of community-driven initiatives and ecosystem sustainability, I require more information or am neutral on the impact of the proposed referral incentive system.
Conclusion:
This proposal represents a strategic step towards leveraging the Gala Founders Node Ecosystem’s full potential, encouraging active participation, and rewarding contributions that drive the ecosystem forward. Through collaborative efforts and a shared commitment to innovation, the ecosystem can continue to evolve, offering increased value and opportunities for all participants.
You may have recently heard rumors about how Gala Founder’s Nodes constitute a large portion of the decentralized internet and IPFS. It is true that our Founder’s Nodes make up nearly 30% of the most active stable peers in the IPFS Distributed Hash Table (DHT), but that is only the beginning of the story. The Gala Founder’s Node ecosystem, with almost 24,000 DHT servers online, represents a massive contribution to decentralized storage and computing, powering the largest share of any single network contributing to IPFS today!
In this blog, we’d like to shed some more light on how this fact was realized, involving a coincidental misconfiguration over a year ago that shed light on the actual portion of the decentralized internet that was powered by Gala nodes.
We think that this is an incredibly interesting story about the resilience and security of decentralized networks, and one that is especially relevant today as we prepare to onboard greater numbers than ever before to our sustainable and capable L1 blockchain, GalaChain. But first, let’s talk a little about IPFS and the role that Gala Founder’s Nodes play in supporting the very existence of the decentralized internet protocol known as the InterPlanetary File System.
We want our non-tech-genius followers to understand and appreciate the significance of this story, so we’ll try to keep it simple as we explain. But feel free to check out THIS ARTICLE from Probelab.io for a more in-depth approach with more charts and data.
What is IPFS?
The InterPlanetary File System is a web3 internet protocol that began in 2015, designed to decentralize and democratize ownership of content on the internet.
In simpler terms, it is a solution for the storing and sharing of files, a decentralized answer to cloud-style storage.
Instead of uploading files to specific servers, they’re broken into small chunks and scattered across many computers around the world. Each chunk gets a unique fingerprint called a CID, like a personalized code.
To access a file, all that is needed is its CID. A special network called the DHT (like a giant, decentralized phone book) helps users locate the computers with specific chunks. Finally, the chunks are downloaded from those computers and pieced back together.
The DHT is maintained by nodes from the various peer networks of IPFS, like expert operators who are able to quickly look up and retrieve encrypted data from IPFS. Think of Gala Founder’s Nodes as some of the best information operators in the game, with enough storage capacity and bandwidth to ensure that the most important files are always accessible, anywhere online.
Illuminating Mishap
In January of 2023, a slight misconfiguration of Gala Founder’s Nodes in IPFS’s libp2p resource manager caused Gala Founder’s Nodes to become unresponsive within the IPFS network for a short time. The downtime was only a matter of a couple hours, but the number of unresponsive nodes was so impactful on the total number of network nodes that more research into the issue was warranted by IPFS.
Because they knew (because of the misconfiguration) that the unresponsive Nodes during that time were in fact Gala Founder’s Nodes, IPFS was afforded a rare opportunity for what was essentially a snapshot showing the portion of Gala Founder’s Nodes from the entire pool of DHT server nodes.
In THIS ARTICLE from the IPFS blog, the unresponsive node mishap (pictured above) was described, along with the solution that was quickly implemented.
Perhaps the most interesting thing about this incident was that even with about 60% of its nodes unresponsive, the DHT was still able to deliver content as intended, keeping IPFS running, just a little slower than normal. This is a testament to the power of the decentralized internet, where software can be updated on the fly across multiple distributed node networks without negatively affecting the performance of IPFS.
Uncovering Gala’s Role
Because of the intrinsic encrypted security of decentralized networks, it can be difficult to draw specific information about where support is coming from. However, in this situation, the technicians at Interplanetary Shipyard were able to draw some interesting results from the data. They were even nice enough to share them with us when we asked for a quote in early February of 2024:
“Our latest numbers say that 5321 out of 20093 peers that appeared online the past week (have been online for 80% of time or more), have been Gala peers. That makes for more than 26% of the network. I’m sure there are more Gala peers in the network and that the IPFS network has more peers too, it’s just that these are the most stable ones.” – Yiannis Psaras, IPFS Shipyard
It’s worth noting that we have a lot more than 5321 Nodes running every day. This number is only the most active Nodes in the ecosystem, and it still makes up a MASSIVE portion of the total peers on the network. There are tens of thousands of other nodes running in the Founder’s Node Network as well, showing how much further we could flex together if we needed to.
Thanks to Probelab
We’d like to especially thank Yiannis Psaras (quoted above) and Dennis Trautwein from Probelab, who have assisted us with this data. Probelab is one of the largest contributors to IPFS Shipyard, a collection of open source projects created and maintained by members of the IPFS community.
Probelab is a Benchmarking and Optimization Team “on a mission to measure the performance of Web3.0 network protocols, benchmark protocols against target performance milestones and propose improvements to their core design principles.” (from the Probelab introduction)
These folks are heroes of the decentralized era whose work is always needed but rarely seen. Thank you so much for all your great work in web3’s foundations!
We’re downright proud that our Founder’s Nodes make up such a large portion of the DHT server nodes. Still we may be even prouder that when those Nodes were down, the decentralized internet kept right on going and didn’t miss a beat.
