3 ms·

I think the browser plugin is a gigantic step. We're talking a whole new generation of browsers with native support having to roll in for this to gain traction,

I think the browser plugin is a gigantic step. We're talking a whole new generation of browsers with native support having to roll in for this to gain traction, and most consumer traffic is mobile nowadays so it's not enough to ship to a PC and be satisfied there. If it were to gain mainstream attraction it seems like we're talking at least five more years unless the chromium and safari teams pick this up and make it a priority.

xrd 5y ago
I totally agree. Other than Brave, it will be years until web3 is seamlessly intergrated. But, my point about L2 solutions is that with those you have a work around. web3 requires that you use secp256k1 ellptic curves. Those are not available in any browser. So, you cannot sign transactions. You cannot participate in Ethereum from a browser. But, what if the L2 network does not require that curve? What if it accepts WebCrypto signed L2 transactions? Then, you can participate in Ethereum through L2. You might give up a little in terms of absolute security (these still have much better security than anything else out there, by the way), but for certain applications that might be a tradeoff worth having. If you can manage transactions in a vanilla browser using WebCrypto (or bundling your own crypto in JS with browserify or something -- that's what I did), and the API is over HTTP instead of into an Ethereum node, then you can participate in a vanilla browser.
- ck_one 5y ago
  Why can't browser natively sign transactions using secp256k1? And why is that not required for L2 transactions?
  - xrd 5y ago
    Browsers don't have that cryptographic primitive available. L2s can choose whatever encryption schemes they want. They could use rot13 if their customers would be willing to work on a L2 chain with that compromise. :) A blockchain (if you already know this, sorry...) is just a ledger with transactions created using public/private keys. Ethereum (and Bitcoin) use secp256k1. But, each blockchain can choose their own and L2s have different ones for different reasons. Eventually the L2 needs to put something back on L1 and that transaction has to be using the crytpo the L1 uses. But, the L2 can store into the L1 the answer to a ZK-proof (with the answer as a link in a Merkle tree), and how you manage transactions (and that Merkle tree) inside the L2 is up to the L2 managers.

xrd 5y ago

I totally agree. Other than Brave, it will be years until web3 is seamlessly intergrated. But, my point about L2 solutions is that with those you have a work around. web3 requires that you use secp256k1 ellptic curves. Those are not available in any browser. So, you cannot sign transactions. You cannot participate in Ethereum from a browser. But, what if the L2 network does not require that curve? What if it accepts WebCrypto signed L2 transactions? Then, you can participate in Ethereum through L2. You might give up a little in terms of absolute security (these still have much better security than anything else out there, by the way), but for certain applications that might be a tradeoff worth having. If you can manage transactions in a vanilla browser using WebCrypto (or bundling your own crypto in JS with browserify or something -- that's what I did), and the API is over HTTP instead of into an Ethereum node, then you can participate in a vanilla browser.

ck_one 5y ago
Why can't browser natively sign transactions using secp256k1? And why is that not required for L2 transactions?
- xrd 5y ago
  Browsers don't have that cryptographic primitive available. L2s can choose whatever encryption schemes they want. They could use rot13 if their customers would be willing to work on a L2 chain with that compromise. :) A blockchain (if you already know this, sorry...) is just a ledger with transactions created using public/private keys. Ethereum (and Bitcoin) use secp256k1. But, each blockchain can choose their own and L2s have different ones for different reasons. Eventually the L2 needs to put something back on L1 and that transaction has to be using the crytpo the L1 uses. But, the L2 can store into the L1 the answer to a ZK-proof (with the answer as a link in a Merkle tree), and how you manage transactions (and that Merkle tree) inside the L2 is up to the L2 managers.