I feel like you've misunderstood the papers, and what the motivation behind them is. The argument isn't that Intel chips are more efficient, it is that these schemes simply don't require continuous computations.
As for the two schemes, you are correct about the first paper that it depends on the timeouts enforced by SGX. However, the second paper makes no such assumptions and doesn't even assume that the enclave is secure; all it relies on is the attestation service (which is remote).
As I understand it, the benefit of PoET is that it doesn't require the massive waste of electricity that PoW does.
What I find ridiculous is that they have roughly the same security properties as a timestamping server set up by Intel. Creating a blockchain that depends entirely on one trusted party seems pointless.
The timestamps for PoET don't require centralized servers; the timers are local to the platform. RRR goes one step further and doesn't even trust local timers.
I think you're missing the point being made. GP isn't saying these schemes require a central server.
The point they're making is that PoET assumes that Intel SGX actually provides the properties that Intel claims (namely that they will never produce attestation certificates for code not run in SGX). Thus there is a single party which you are trusting to provide these properties and not attack your system. If you're okay with trusting a single party then the system is equivalent (in terms of security) to having that single trusted party run a server which emits timestamps.
RRR suffers from basically the same problem -- you're trusting Intel to not produce endless fraudulent identities and thus always be chosen as the oldest miner.
Your motherboard UEFI blob and chip both have to support it. The vast majority of systems are limited by the fact their UEFI implementation does not enable (or allow you to enable) SGX at all, and at least on my Ice Lake laptop, SGX was disabled out of the box in UEFI (in a non-software controlled state.)
The main difference is spreading out the control of the database to multiple actors. No single entity is allowed to make unilateral changes to the state of the database.
Moreover, the line between permisisonless and permissioned blockchains isn't necessarily about who's allowed to join but rather which identity they use. For RRR, the only reason we limit ourselves to permissioned is because we require long lived identities to prevent sybil attacks; otherwise it's as "open" as any public blockchain.
The assumption behind PoET is precisely that you don't control a part of your machine (the SGX enclave). I agree that that's an unreasonable assumption which is why we developed RRR.
> I agree that that's an unreasonable assumption which is why we developed RRR.
Out of curiosity, I would've hoped that the consensus in the cryptography community is that "secure enclaves" are pretty much snake oil to begin with... is this not the case?
(I mean... for a secure enclave to actually work, you need "perfect" physical security, "perfect" software implementation inside, and "perfect" design of the cryptographic systems around it... that sounds rather infeasible. I always assumed cryptographers would agree and that it's mostly engineers and lawyers trying to "ship the impossible" to do things like DRM.)
As the article states at the end, no one should assume that enclaves give you perfect security. They are most useful when used as a defense in depth mechanism: a way to increase the cost for a successful attack.
There is no such thing as perfect security - it is always a risk assessment exercise. Secure enclaves in general are not snake oil. Secure elements and TPMs, for example, are evaluated by independent testing bodies to high levels of security certification. These are examples of secure enclaves. Secure enclaves in this context, SGX, are an on-CPU mechanism that have weaker isolation properties than other enclaves. However, SGX has a different set of advantages, and may be acceptable to use based on the value of the asset being protected.
You could apply the same logic to cryptographic systems themselves; we have very few absolute proofs of security properties for the cryptography we use for TLS and the like, so they are “imperfect” and may be vulnerable and therefore are snake oil. However I doubt you’d feel indifferent about whether a website you are sending your credit card number to uses HTTPS and stores your payment information encrypted at rest.
I'd trust much more to software in general (and TLS-based crypto in particular) compared to hardware devices.
The TLS vs SGX is a particularly bad comparison. SGX's internal design was not even published, let alone reviewed; and it already had multiple bad exploits.
The TLS design and code has been reviewed by a multiple cryptographers, and the algorithm itself (not implementation) is unbroken.
You have a very limited understanding of what "works" and what is "impossible", it seems. Actual security engineering occurs in hostile environments all the time, in extremely non-perfect environments, with non-perfect tools, and many of its principles (and practices) noticeably make security better for users, operators, and engineers. Similarly, DRM is not only NOT "impossible", it's very possible, very real, and actively used against people today. I suspect if you truly think DRM is "impossible" you have a vastly more limited understanding of security than you think you do.
Computer people have absolutely got to get out of this mindset where impossible means "according to my made up set of Nerd rules", vs the rules that are in place in the world surrounding them.
No, I have a very good understanding of how most of my users, i.e. "normal" people, operate. I would suggest you pick a random relative outside a STEM field and discuss what their security requirements for a blockchain wallet are.
I haven't "made up my set of Nerd rules." I have learned what the general expectations of my users are.
No one's gonna mention Bloackberry 10? In my opinion it was years ahead of the competition with its gesture based UI and Hub. Also, it felt like something that was truly different from the ios and android phones everywhere.
As for the two schemes, you are correct about the first paper that it depends on the timeouts enforced by SGX. However, the second paper makes no such assumptions and doesn't even assume that the enclave is secure; all it relies on is the attestation service (which is remote).