You are correct, when I say OUR funds, it is of course Autonomi funds but as I (and I guess most of us) have such a deep connection to the project, I regard it as “OURS” 
The cost of ETH is unfortunate, at least its on Arbitrum but it is till adding up quickly.
3 Likes
Okay some food for thought, I am going out on a limb here,
as this is a brain fart on how one might resolve this Emissions reward condundrum where the current state is a small node’s odds of receving them are very small, that said, I am not a fan of emissions, I am fan of upload incentives…
Anyway for what its worth, for discussion purposes technically,
Let’s see, the node-launchpad knows the number of nodes being operated, associated to a wallet address, the node-launch pad or antctl is active running in the background,
then in theory,
with a gossip event msg, the SC can query the randomly selected XOR address antnode, which triggers the antnode to check locally the running backround node-launchpad or antctl PID process and fetches locally that info pair and then publishes an event msg with the number of antnodes run in that dashboard instance associated to that wallet ID, to the SC event query XOR address.
The SC then receives the event msg, adding the discovered pair value into a vertical slot list on some sort of accumulated/adjusted Bell Curve distribution, it is an accumlator of a unique wallet address+ diff or same XOR address.
the data wallet id antnode_count is either incremented if different XOR address, or not(sameXORaddress) and updates emmission_count, again based on the wallet_id+XOR unique ID of the antnode queried
, then the SC Algo dooes what its supposed to do that is either issue the reward or pass and go to the next, based on some adjusting Bell Curve Rules as the Bell curve distribution is dynamic
Seriously, to do any of the above in a SC running on an EVM, one would need the SC to be crafted to run on a VERY high performance EVM, like what FUEL VM (Compatible with EVM) transformed into SC SWAY language, (FUEL’s EVM is modular, so it can be added to any Ethereum Layer 2 side chain)
the FUEL VM is the only implementation of an EVM I know of that has the ability to completely use all the Compute resources thrown at it in a ‘Scale up’ manner, ‘FUELVM’ as they call it, has safe multi-threading and will consume all the CPU cycles and cores cores you throw at the SC to do what is in either of these use case, a ‘scan first then conditionally send the emission or upload reward’
the first is just for joining the network, which is easily gamed as we know,
The same thing applies for the second use case, join and do uploads, which is what I favour personally, but that’s just me.
Of course a native token is the real answer, so evertying stays inside the network…
While I applaud the spirit behind the Drip Facuet to support upload tests and the amount of thinking and tech work done and the donation spirit as well, the cost of doing Drip Faucet is high per upload test (plus this is me talking only, I feel like a trained circus poodle jumping through hoops of fire to get there. ;/ )
The permanent fix iimo is to get the Upload UI Client working across all platforms ASAP , and all of the above technical resource Debt to do it goes away with a collective Big brain figuring out how to bolt the FUELVM directly to the Autonomi Network scheme of things
For the adventurous- Why write an SC in Solidity to run in EVM ‘golf cart’ when you can go way faster run more stuff in parallel by in writing your SC in SWAY to run on Fuel-VM Top Fuelie? 
This is UofT (Toronto) stuff spun out first with Celestia, then Fuel Labs sprung up with Fuel-vm and SWAY SC language…
I wrote about it here awhile back
https://www.publish0x.com/breaking-the-small-wind-mold-darwind5-circa-2012/fuel-vm-and-celestia-flattening-l2-to-l1-onchain-with-sway-s-xzqndey
Anyway food for thought, and, I am back to work…
1 Like
So, no port forwarding assigned better, or worst? I am not quite sure how small farm setup to overcome the Nat issue, 300 Nodes actually not a huge number.
It used to be 30 nodes overloaded a router. With better optimisations the count is perhaps higher. But even with port forwarding the router is keeping track. Also your node is corresponding to the majority of the network using their ports, which the router is also keeping track of. Only unsolicited packets will specifically come through the port-forwarded ports. Those unsolicited packets come from clients and sometimes a node will do that too.
The router is not something the software can fully overcome. There has been a lot of improvements by reducing the number of simultaneous connections needed, but cannot reduce too far since there is limits.
Originally having 30 nodes was considered large setup and very original plan was one node behind any IP address.
For the typical home user the number of nodes will be small, they are not technical and their spare resources may be computer with 256GB or 512GB older computer. But in any case 30 nodes is not such a small number
For the early people who are typical more tech savvy in computers and this distributed world, we want more and more nodes. There are always limits and if it ends up being the router then you have to ask yourself the question. “Am I that motivated to have more nodes and willing to upgrade my router to something better?”
Basically if what you have is not good enough then you have to get better. Distributed networks need connections to work fast and reliable. If you consider that a node has one connection then it has to hop one step at a time through the network with 50mS to 400mS lag time to each response. Might take you minutes just to find the node you need to talk to.
2 Likes
What router are you using? My router with 1G ram, 300nodes easy filling up Nat table. 8000 nodes !?
Its based off FREEBSD/pfSense. Custom built router with generic computer parts.
NAT session table at 1M+ with 32GB of RAM and 6 Core CPU.
1 Like
Is it VyOS? I am trying to build one, like 8 core A55 with 16GB ram🤔