Nym promises to be the 'better than #Tor' anonymous network - a bold claim but one she says they don't make lightly.
@stman what about printing the messages on paper? or passing thru a transformer that displays an easily verifiable artifact?
unused bits as indicated in specs must either be formally-verified to ensure against their use or removed altogether - possibly making for awkward packing or inefficient representation.
@theruran What cryptographic ways are you thinking about ?
And yes, would remain only a serialization issue, but by the way, such issues would be greatly simplified if we are in a fully synchronous paradigm.
The directions of research we have been revealing slowly with all our talks and debates are very coherent. It is obvious we are on the right path to what we want to achieve.
This is the project I was remembering and referencing in my post:
An Ironclad App lets a user securely transmit her data to a remote machine with the guarantee that every instruction executed on that machine adheres to a formal abstract specification of the app’s behavior. This does more than eliminate implementation vulnerabilities such as buffer overflows, parsing errors, or data leaks; it tells the user exactly how the app will behave at all times.
Going through the cryptography section of their website and I found some related topics that may be of interest: verifiable computing, homomorphic encryption, Secure Multi-Party Computation and EzPC, Certification of Symbolic Transactions, and Differential Privacy (also under Database Privacy)
This may catch your attention, from the EzPC page:
Secondly, to execute these protocols, one must express the computation at the low-level of circuits comprising of AND and OR gates, which is both highly cumbersome and inefficient.
So there's a lot here that ought to stimulate your imagination. This is what I imagine for the future of computing is that these cryptographic mechanisms are native and used to guarantee privacy of data and computation.
@stman @yaaps I like your idea of using LETs to display the self-test process and output. Earlier what I mentioned about printing or displaying an artifact is really a checksum that is easier for humans to visually check. If there are 1000 LETs that display a stable output at the end of the self-test, it can be very easy to miss a few LETs that are not illuminated but which may indicate a drastic difference of the IC behavior. So a checksum is more user-friendly for this purpose, but maybe you are concerned about its implementation correctness, since after all, how do we know the checksum algorithm is correct or can be trusted? What I am imagining is a printed image in the computer user manual of the correct self-test output, that the user can verify at any time by running the self-test.
How do you know you own the machine?
If you compile an AST to gates, that's a minute, hyper-detailed accounting of the implementation. If you represent and gates and or gates as ones and zeros, the final representation is unlikely to compress more efficiently than a source code representation. So, yes. Bulky, high bandwidth, and inefficient. But...
You might still want that for a bootstrap
@stman @yaaps It's a more difficult issue because you are talking of compilers, but the research I referenced above describes how to ensure the remote machine is executing your program according to formal semantics. The benefit of sending HDL instead of TTL would be less information on the wire.
I don't understand what you say here about Abstract State Machines. It's another abstract machine that is represented mathematically (formal semantics). As with any abstract machine, we can theoretically implement it in hardware just as they did with the LISP microprocessor. The output and stepwise process of an ASM can be tested on many different machines using different software, thereby using the principle of redundancy to verify correctness. It can even be implemented as an FPGA softcore (again theoretically, I don't really know about the space requirements of typical ASMs versus what's available on a run-of-the-mill FPGA).
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!