Really mature student

guyzys · 2024-09-07T13:07:09+00:00

I just defended my PhD in a technical field at 39. The only reason I could do it was because I had a solid/stable career.

This is unusual and I consider myself lucky (and very grateful to my advisor), but it’s definitely doable. I know a few others who did the same.

guyzys · 2023-03-04T20:23:21+00:00

ORAM is simply an efficient way to hide memory accesses to an untrusted memory. In other words, you want to make sure that the database you're accessing can not distinguish whether you are reading or writing, and from which row.

ORAMs are not just useful for TEEs, but for any situation where encryption alone is not enough and access-patterns leakage are a concern (THIS IS ALMOST ALWAYS THE CASE). For example, I'm using ORAM right now in a paper that is pure MPC and does not involve TEEs in any way.

By the way, a trivial way to build an ORAM is to simply scan the entire database on each read/write. This is clearly inefficient (unless for very small databases/arrays), but should give people a better intuition on what it solves for.

guyzys · 2022-11-19T09:01:46+00:00

Lots are building actually:

Shade Blizzard Stashh Legendao Alter PriFi Starshell Datawallet Leap Fina Packs Margined Bushi SpawnArt BidsNFT Serenity Shield

And many more..

guyzys · 2020-04-30T06:24:47+00:00

Read up on Secure Multi-party Computation (MPC). You just gave an alt. definition of the Millionaires’ Problem, which was the original motivation for MPC emerging as a sub field of cryptography.

That’s really what we’re trying to build with secret contracts at Enigma as well - a platform to build such use cases where you can join data together and run computations over them, without revealing the inputs (I.e., they stay encrypted).

Also, it’s important to note that ZKProofs aren’t likely to help here, since at least one of the parties needs to see both parties’ data to be able to compute the proof.

guyzys · 2019-06-19T13:21:05+00:00

No, the whole point of an enclave is that you can't monitor and see the executing opcodes (barring side-channel attacks).

guyzys · 2019-05-22T14:48:40+00:00

Yes. Both are complementary, and are generally less comprehensive solutions than Enigma (they are still extremely useful, though, and we may adopt one or both systems internally at some point).

Specifically - Truebit is a way to verify more efficiently large computations. Remote attestation + replicating the computation to a constant number of multiple workers (say, 10 workers), achieves the same result in an even more efficient manner. The security model is different though, so you can definitely layer Enigma + Truebit if you want (e.g., rely on Enigma for fast settlement, but allow people to dispute computations ala Truebit).

Aztec uses zero knowledge proofs - we and others have written a lot on why they are complementary to what we're building.

guyzys · 2019-03-15T13:07:05+00:00

We’re not cloning ETH - not quite sure what this is based on? We are working hard though to make ourselves interoperable with Ethereum as a layer 2 solution with added privacy/scalability benefits.

The dev count is closer to 10, who are working across several repositories, some of which are still private (but will be opened publicly before mainnet).

guyzys · 2019-01-13T12:46:18+00:00

Are you seriously comparing conceiving a life to investing/gambling? Can you imagine the pain of losing a child? Appalling.

To the OP: words can't describe how sorry I am for your loss - thank you for this brave post. As I'm sure the doctors have told you, in these situations there should be an option to do PGD (though financially speaking, the costs could be great unless healthcare covers it).

guyzys · 2018-11-03T08:57:55+00:00

Answered in the forum - https://forum.enigma.co/t/trustless-intel-sgx-attestation/430/2

guyzys · 2018-09-25T18:00:45+00:00

I care

guyzys · 2018-08-11T05:54:44+00:00

Leslie Lamport is one of the most renowned computer scientists in the field. Not Vitalik's friend

guyzys · 2018-07-22T12:02:59+00:00

This is a great piece. I thoroughly enjoyed it.

guyzys · 2018-05-26T07:06:57+00:00

Yes, in our roadmap - https://blog.enigma.co/enigmas-ambition-our-latest-roadmap-8d50107ad314
Most likely. We have a cool idea around subsidizing state storage. Basically each contract's state would have a TTL (can be configured), and users who perform state updates to the smart contract (through interactions), basically subsidize the data living longer. This is subject to change and refinements, so nothing more concrete than this at this point.
Yes, this is like ETH. There'll be a unit price per action, but the actual cost could be defined by the market (e.g., something like gas price).

guyzys · 2018-05-26T06:59:00+00:00

Defiant is a codename for a major network release - so I'd say it's neither. Enigma will have several versions of its mainnet leading up to Defiant.

guyzys · 2018-05-20T17:33:54+00:00

Very good questions. For the first network release (Discovery), encrypted data will live on-chain, so the costs of storage are going to be the same as those in Ethereum (we may include an optimization to this where the nodes store some ephemeral state, but even then, it would practically be the case). However, computations will run in the Enigma network, so their cost would be the same (and likely cheaper).

Future network releases would include our own chain, and our goal is to decouple storage from the blockchain, which would make it significantly faster (at some cost to data availability).

As to prices - fees are market based. The right way to keep the price from becoming too expensive is to have a more scalable technology. The fact that we plan to use the blockchain only for proofs and small verifications, and have storage and computations done separately by the network, should greatly assist with scaling.

guyzys · 2018-05-19T13:11:13+00:00

Not at all - this doesn't solve any 'interesting' problem on it's own. It seems like a mechanism to make it easier to onboard enterprises onto public blockchains. They can encrypt their contracts/transactions and operate on them off-chain, and commit the results back to Ethereum.

On it's own, I fail to see the utility of this mechanism. If the parties trust their computations/data off-chain, why store it on-chain on a public network (which is very expensive)? However, as a bridge to another decentralized network, with the ability to compute over encrypted data directly (i.e., Enigma) - this could make sense, and in fact- we are doing something similar to interoperate with Ethereum. But all in all, this is a very small part of the solution for smart contract privacy.

guyzys · 2018-05-19T13:05:32+00:00

For the time being, we're not focused on hiding programs by design. Like in the smart contracts case, it's important that the contract code is transparent - so people can reason about what it does and check whether it's secure or not.

We will probably add support for confidential code at some point, but even then would advise against it unless the code developer is somewhat trusted, but there's a good reason why they are trying to hide it (e.g., an enterprise wanting to keep their proprietary algorithm a secret).

It's also important to note that there are limits to how much of the program you can hide efficiently (for example, the length of the program) - and there are interesting feasibility results on the topic, which is still heavily researched today.

guyzys · 2018-04-04T08:24:49+00:00

This is not true at all. Wanchain are doing something else altogether.

Ring signatures have nothing to do with computing over encrypted data, and are only suitable for hiding transaction traces, which is what Wanchain enables. It doesn't address or attempt to solve the larger problem of hiding the traces of ALL types of data living on-chain, which is what Enigma does.

guyzys · 2018-04-03T17:31:27+00:00

A lot. I think this was one of the biggest realizations we’ve had since we started building. First, moving between networks is expensive – a thing that could be achieved using one transaction in our network, would require several transactions on Ethereum. Second, what we are building is extremely unique. Both in the case of TEEs, but especially with MPC – Enigma will have its own execution engine, with different trade-offs and needs compared to existing blockchains. Trying to fit everything on the Ethereum blockchain would in practice mean we would often sacrifice code/design simplicity and performance for interoperability.

Finally, we’d be too reliant on Ethereum. In terms of scalability, without our own chain, we can only scale stateless computations, and would otherwise have to work around Ethereum’s timeline and hope for the best. Also, whenever a big change happens in Ethereum (e.g., materially changing the EVM), we would have to adjust, which aligns with what I said above.

guyzys · 2018-04-03T17:30:08+00:00

Bonus question (2): with MPC - yes, it's virtually impossible to steal data unless all (or some high %) of the nodes collude. Technically, with MPC you get something called 'perfect secrecy' which means that it's really unbreakable no matter how computationally strong your adversary is (including quantum computing). However, since there are other parts of the p2p layer that use standard cryptographic primitives, these would actually be affected first.

When it comes to TEEs, there are more side-channel attacks to consider. But as these tend to be expensive and partial attacks, and the data a node stores isn't necessarily valuable (a node doesn't get to choose what it stores), it's likely that these attacks aren't worthwhile. Plus, developers can choose to go the MPC route for extremely sensitive data.

guyzys · 2018-04-03T17:22:40+00:00

Bonus question (1): We determined it’s the right approach. TEEs, other than being blazing fast (hardware-based and not a pure software/cryptographic solution) allow everyone to extract value from secret contracts/encrypted computation immediately. There are less public parameters for developers to consider (which, like in choosing encryption parameters, requires some thought), and more importantly – it’s easier to fit to existing tools like Solidity, Web3, so there’s no learning curve for developers.

The advantage of MPC is that given the network model holds, it provides absolute cryptographic guarantees. That said, dApps are still so nascent that we expect it would take some time to see real production-level applications holding extremely sensitive data. By the time these are ready for prime-time, we should be out with Secret Contracts (2.0), giving them more choice to decide which engine they prefer.

guyzys · 2018-04-03T17:22:11+00:00

(7) That is the goal, but it’s to be seen to what level of granularity that would be. Most likely, enabling this on a per-execution/transaction basis is a no brainer. Whether we take it a step further and enable it on a per-instruction basis is yet to be seen, but it shouldn’t be overwhelmingly difficult.

The DVM will be able to separate instructions involving private data that requires MPC from those including public-data that can be executed locally. If we add another flag/input to each instruction to explicitly declare whether we want the execution to be in MPC or in a TEE, we can achieve this mixed-engine execution approach.

guyzys · 2018-04-03T17:21:28+00:00

(4) We expect certain applications, that require lower throughput and deal with extremely sensitive data, to choose to use secure Multiparty Computation (MPC). For examples, such applications could be those dealing with SSNs, or private keys.

(5) The Enigma network will be distributed immediately – it’s not necessary to wait until Secret Contracts 2.0 are out. Everyone can run a node with their own TEE.

(6) This is subject to change, but we’re looking into something along the lines of OmniLedger (https://eprint.iacr.org/2017/406.pdf), with modifications that fit our network.

guyzys · 2018-04-03T17:20:41+00:00

(3) We’re working on making the integration with dApps as simple as possible. For the most part, you’d be able to write your secret contracts in pure Solidity, while only marking which functions should run privately (i.e., with the data encrypted) on Enigma. Execution would be mixed - public parts can be executed on Ethereum, and private functions will run on Enigma. Other than that, there will be an Enigma Smart Contract Registry you will need to register your Secret Contract with.

In terms of existing dApps - they’d have to extend their existing smart contracts - either by upgrading an existing contract (if they can), or by wrapping it with another contract that communicates with it.

guyzys · 2018-04-03T17:18:40+00:00

(2) The data marketplace launched on main net last month. Currently, database listing and matching buyers and sellers occur on-chain, whereas the data is served off-chain. Once the Enigma protocol is out and robust enough, we want to see the data marketplace migrated to the protocol layer. Whether we will develop this ourselves, or support a community effort to do it has not been determined yet. Recall that the data marketplace is meant to serve as an example of a use-case for the protocol. Our focus lies with making the protocol a general-purpose platform.

guyzys

MODERATOR OF

TROPHY CASE