Silver Booster (request for comments)

#1

Hi everyone,

After considering input from the discussion around boosters, we have a proposal for the first booster to bring live on the Grid. This booster is intended to promote the same aims as Gold Certified farming, and so it is called the “Silver Farming Booster”. Unlike Gold, this is not a new certification category, but rather something farmers can achieve simply through the measured performance of their nodes and network. It is also proposed as temporary, to be periodically reconsidered and adjusted or retired as appropriate.

The Silver booster is based around many of the same specifications required for Gold farmers. It aims to reward farmers who bring a higher level of service with their nodes, which comes with higher costs for hardware, network connectivity, and infrastructure needed to provide high uptime.

Farmers whose nodes meet these requirements would receive the same boost to farming rewards as Gold Certified farmers. Gold Certified farmers will still hold the benefit of having increased rewards for a period of five years, versus a limited time booster.

Before getting into the spec below, I’ll also note that other boosters are still under consideration, especially boosters for utilization.

Silver Farming Booster

Requirements (this is a draft, please comment in the replies):

  • At least 2 SSDs
  • Enough SSD capacity to support available CUs (else add more)
  • At least 5 pub ip addresses per node (averaged out over farm)
  • CPU performance of 1800-2000 Passmark score per thread minimum (*) (**)
  • MEM enough bandwidth to the CPU (DDR3 or higher) (*) (**)
  • Adequate network performance, 50-100mb/s symmetric per node (*)
  • 99.8% min required uptime over last 30 days (*)
  • 98% min required uptime over last 60 days (*)
  • 98% min required uptime over last 90 days (*)
  • Support for working TPM 2.0 module and accessible in our ZOS operating system (*)
  • Electronic signing of terms and conditions service provider contract.

(*) as proven by TFGrid Audit Tool (TFGAT), node needs to have run the TFGAT at least 30 days before it can be eligible for silver farming booster.
(**) team is working on specs and prototype code on how to measure performance of CPU and MEMORY and required specs in an optimal and fair way.

Rewards:

CU: +50%
SU: +125%
NU: +50%
IPv4: +0%

Start:

As soon as the Grid Audit tool is ready and required data can be collected (November/December 2022)

End:

Initial run for one quarter (3 months).

1 Like
#2

Will this be a a mandatory requierement? If yes… 12th gen Dell and 8th gen HPE servers won’t be fitting!

#3

Correct, still rules out the tons of great r620’s running in tier 3/4 DC’s. :frowning:

#4

I have been looking at this, the r620 can have a tpm, but it was a factory option and wasn’t offered as a post sale addon. Working on getting my hands on one to rip apart and try to find the circuits for it, I’m hoping I can add a header. There may be hope yet.

1 Like
#5

I honestly don’t know if anyone has ever really walked through why this is coming up and what the spirit of this rule is. I think sharing that will make it a somewhat easier pill to swallow but more importantly offer the opportunity for a community brainstorm on how we can achieve the same goals with hardware like your 620s and my g8s.

First of all understanding what a tpm is, is paramount for reference,

but the important piece of the puzzle is that its a dedicated device that stores keys and performs cryptographic tasks in order to further secure data, running applications, the operating system, and the device. Without a TPM there is critical failure point with a users data that is the farmer themselves, with physical access to the node it is possible to boot into other operating systems and retrieve data directly from the disk in cases not including QSFS.

The problem lies with a catch 22, users of qsfs expect reduced performance because of the time spent decrypting when accessing files, if the files of for instance a vms root fs were encrypted all the time it would be a nightmare for responsiveness. what the tpm enables is for zos to not let other operating systems access those disks without them being unlocked.

the reality is the need for being able to secure a users data from access by a farmer is not optional in the overall scope of the project but the need for a TPM could be optional with alternative solutions not requiring the presence of the TPM but achieving the same goals. right now this is the only solution that exsist and is one of the huge benefits to deploying on certified nodes.

I think another solution is to have make the presence of the TPM an add on reward, and have base rewards for nodes without, the TPM does in fact offer additional features over nodes without and this is probably something we should have front acing badging for. there are a lot of workloads that I wouldn’t be concerned about running on nodes without a TPM. some of the most basic things, reverse proxies, dns servers, public facing ftp servers are all things that could be offered as one click setup on the grid that don’t require the application/device security of a TPM.

#6

@ParkerS of course everyone is aware of the benefits of TPM. But as you already said… there are countless usecases where TPM is not needed.

I really don’t understand why TPM support and running nodes in DCs is put into the same pot. Why can’t you guys just understand that there is a major difference of nodes being run in tier 3/4 DCs in compare of being run in a garage/cellar or anywhere else… no matter if thoses nodes have TPM support or not. Tier 3/4 DC farming results in highly predictable uptime/availability due to secured environmental conditions, failsafe powersupply, redundant and resilient networking infrastructure. That’s the benefit! That’s the reason why DCs exist! I have never seen a DC with a sign on the front door saying “servers with TPM-support only”. Renting a rack in a tier 3/4 DC (in a Western European country) together with a proper ISP uplink (>1Gbit dedicated bandwith) and a /24 block of public IPs costs thousands of EUR per month. Plus additional costs for electricity depending on power consumption/utilization. If you guys don’t see the added value of DC farming in general (even if these nodes do not support TPM) than please let us know. Then we can save ourselves the discussion.

It’s been now 6 weeks since we found out that gold certified farming program is not meant for “us” but was developed for “others”. Within the rising dicussion boosters where announced which would help to be “rewarded in line with our efforts”. And now we are at the exact same point like where we have been 6 weeks ago. In the meantime the TFT value dropped below 0.03$. I’m speachless…

2 Likes
#7

The dc isn’t concerned about protecting the data on the hardware from the person that owns the hardware. I understand all of the conditions that your deployment offers, but do you have a solution to being able to protect a workloads data from you, the farmer, without a TPM? I don’t think i agree with the need for a TPM in this setting either though. This is just gold certified being applied retroactively based on results. it shouldn’t be its own feature. should just be a feature of gold certified that identifies nodes without an application.

I feel your pain though. I receive nothing extra for my 5 gigabit network, nothing for the cockpit project or any of the other work I do here. there definitely has not been much happening in the way of actually encouraging people to drive utilization or do more then buy certified and plug it in.

The only true answer to fixing farming reward and node profitability is for people to be using the network and need to buy the token driving token price.

#8

I think that the farmer is the least danger to his/her own nodes. I do think that TPM is a reasonable way of adding another security layer, but I also know that TPM can be hacked (see blog from Dolos group).

That’s exactly what I wanted to point out. Why can’t TPM-support be a feature on it’s own… maybe with it’s own booster. Why must there be a mandatory connection with TPM and DC farming?

and that’s exactly what boosters (in my opinion) should be for. To reward the added value of enhancing the grid (above standard deploys) in order to help cover costs.

although I have been a bit quiet in the last time I do have followed your work. It’s incredible how much useful output you generated in the last time. Nice job!

#9

I believe the benchmarks requirements would also disqualify them.

#10

I was gonna say, I swear I have some servers with a TPM chip.

#11

…also does that means that for example E5-2660v4 (1654 passmark per thread) and E7-8880v3 (1574 per thread) wont qualify, but the E5-2690v2 with 1884 score per thread will? - isn’t that a bit of a paradox?

Dany I did not get that the TPM would be mandatory from what Scott wrote, - just wont be able to qualify and get “Siver Booster’s”

#12

It’s mandatory for the booster and gold certified he’s bringing in pieces from a much larger discussion

#13

Well, the “90” in 2690 indicates a higher level of performance than the “60” in 2660. I wouldn’t say it’s a paradox that an early generation of a high performance model out performs a later generation of a lower performance model.

Comparing the 2660 v3 to v4, we see that the per thread performance has decreased, while the thread count has increased substantially, from 20 to 28. If you were shopping for a CPU for a dedicated server, the v4 probably provides better performance for many applications. However, in a shared environment, you are shopping per thread, so smaller reservations will have better performance running on the v3.

That said, I was basing this figure from an incomplete view of what CPUs are already in the field in our Gold Certified farms. It turns out there are some certified nodes with per thread Passmark scores in the 1500s, so perhaps we should consider 1500 as the cutoff instead.

The TPM serves two main purposes within Zos, at least to start. First is managing node identity in a way that’s strictly tied to device hardware. Second is providing a cryptographic root for features like at rest encryption.

Without making TPM a requirement for all hardware on the grid, we can’t rely on this as the sole way to manage node identities. It will take more time to build out the other TPM based features and demand for them. Personally I don’t think that TPM should be required in this spec, but other members of the team feel otherwise.

That’s one reason that we’re bringing this proposal as a request for comment. If we hear from the only farmers who are able to meet the other requirements that they don’t have TPM chips in their nodes and can’t add them (that is, without replacing the mainboards in the case of the r620s), perhaps this should be reconsidered.

If you read the article, you’ll see that this exploit was made possible by the fact that Bitlocker doesn’t user certain features of the TPM that enable secure transport of secrets across the buses that they tapped into. This article might serve as a guide on how we should harden our use of the TPM, but it doesn’t prove that TPM is not a useful tool to achieve greater security.

#14

looks like we have to go from this… (yes… that’s our farm!)

6
6480×640 132 KB

to this…

Screenshot 2022-10-14 115637
Screenshot 2022-10-14 115637718×1036 203 KB

Much more cost efficient!!!

But I am a bit worried about the 56k dial up-modem you can see on top of the right shelf. Even this is high-quality-hardware it could be a single-point-of-failure? What you think?

2 Likes
#15

So we expect the people in third world countries where the internet does not currently exsist to only use modern hardware with TPMs :face_with_raised_eyebrow:. I’ll be honest I don’t particularly care how many different crypto projects nodes can be deployed on the grid or if I can keep earning once my nodes go to sleep and never reawaken because there’s no workloads to be had.

There needs to not be another moment of time spend on developing anything until we can come up with a actual document that can tell farmers what hardware is required to participate whether that’s basically or in apparently any program other then the absolute basics. I personally will not be buying anymore hardware till a solid position is taken on this issue.

My payout for 66 cores 756gb of ram and 8 tb of ssd was 135$ there’s isn’t a chance in the world I’m buying multiple thousands of dollars in new servers with Tpms when I can’t even cover 1/2 of my farms internet bills with the rewards. If I was here for the rewards, I can imagine I’d be moving forward.

1 Like
#16

Oh yes… a propper documentation would be great!

That’s what you can find when you are looking for “TPM” in the TF-library:

image
image722×321 6.9 KB

I just don’t know how to handle that amount of information!

#17

We are clearly an organization suffering from a lack of shared mission, vision, and values. Can the “other members of the team” come join the discussion it seems there is a lack of ability to communicate across the table here if there’s people making decisions that don’t want to be involved in the conversation.

2 Likes
#18

Not sure where you’re reading that. There’s no suggestion whatsoever to require a TPM in all nodes. The intention here, as with the booster discussion in general, is to provide additional rewards to farmers who have made additional investments, in this case modern systems.

Specifically when we’re talking about Dells like in Dany’s farm, the 12th generation (R620, R720, etc) had TPM available as an option, but they can’t be added after purchase. The later generations all support installing TPM as a snap in component. The 12th gen was produced from 2012-2014, meaning these units are 8-10 years old.

10 year old machines can certainly still do lots of useful work and remain reliable with proper care, but I think it’s about the reasonable limit of hardware age that we should be encouraging anyone to bring online on the Grid.

That’s, well, exactly what we’re doing here: discussing potential requirements for classes of nodes that are eligible for extended rewards. Requirements for the basic participation on the grid are well established. Before we add any new sections to the wiki about what the requirements are for different kinds of farming, we need to define them, and these are still up for discussion here!

To be honest, this kinda reminds me of my farm in the basement. Just add a bunch of huge spiders and tidy up the cables a bit :rofl:

In all seriousness, I’m trying to move this conversation forward in a genuine way so we can find a solution through compromise. Your replies give me the feeling that you didn’t actually read what I wrote, or don’t want to engage in an earnest discussion.

There’s nothing about TPM in the wiki… because it’s not a current feature or requirement of the Grid! It’s part of research projects and proposals for future features and requirements, which you can find many references to in this forum and in the relevant Github repos.

This is a proposal for a new program with new requirements. We don’t document proposals on the wiki. We discuss them in the forum.

#19

Im not sure how to do the section quote but paragraph five of the post says I was replying to above from you

“Without making TPM a requirement for all hardware on the grid, we can’t rely on this as the sole way to manage node identities.”

I may have mis understood the intent

#20

Just highlight the text you want to quote, and a little quote widget pops up :slight_smile: I haven’t had luck with that on mobile. You can also put the greater than sign > at the beginning of a line to format it as a quote without the reference to the previous post.

I see why that part of my post was confusing. I was actually giving reasons that I don’t think incorporating TPM into the Silver Booster requirements makes sense. Since we are not planning to require a TPM for all nodes on the Grid, we will need another way to manage node identities that ties them to hardware as intended.