Vitalik tungkol sa posibleng hinaharap ng Ethereum (Ika-anim): The Splurge

Sa disenyo ng protocol ng Ethereum, halos kalahati ng nilalaman ay tumutukoy sa iba't ibang uri ng EVM na pagpapabuti, habang ang natitira ay binubuo ng iba't ibang mga niche na paksa, at ito ang ibig sabihin ng "Splurge".

Orihinal na Pamagat: 《Possible futures of the Ethereum protocol, part 6: The Splurge》

May-akda: Vitalik Buterin

Pagsasalin: zhouzhou, BlockBeats

Ang sumusunod ay ang orihinal na nilalaman (para sa mas madaling pag-unawa, ang nilalaman ay inayos):

May mga bagay na mahirap ikategorya sa iisang klase lamang, at sa disenyo ng protocol ng Ethereum, maraming "detalye" ang napakahalaga sa tagumpay ng Ethereum. Sa katunayan, halos kalahati ng nilalaman ay tumutukoy sa iba't ibang uri ng EVM na pagpapabuti, habang ang natitira ay binubuo ng iba't ibang mga niche na paksa, at ito ang ibig sabihin ng "Splurge".

2023 Roadmap: Splurge

Splurge: Mga Pangunahing Layunin

• Gawing high-performance at stable na "final state" ang EVM
• Ipasok ang account abstraction sa protocol, na nagpapahintulot sa lahat ng user na magkaroon ng mas ligtas at mas maginhawang account
• I-optimize ang ekonomiya ng transaction fees, pataasin ang scalability habang binabawasan ang risk
• Galugarin ang advanced cryptography upang mapabuti ang Ethereum sa pangmatagalan

Mga Pagpapabuti sa EVM

Anong problema ang nalutas?

Sa kasalukuyan, mahirap ang static analysis sa EVM, na nagpapahirap sa paggawa ng efficient na implementation, formal verification ng code, at karagdagang pagpapalawak. Bukod dito, mababa ang efficiency ng EVM, at mahirap magpatupad ng maraming uri ng advanced cryptography maliban na lang kung may explicit na suporta sa pamamagitan ng precompiles.

Ano ito at paano ito gumagana?

Ang unang hakbang sa kasalukuyang EVM improvement roadmap ay ang EVM Object Format (EOF), na planong isama sa susunod na hard fork. Ang EOF ay isang serye ng EIP na nagtatakda ng bagong bersyon ng EVM code na may maraming natatanging katangian, ang pinaka-kapansin-pansin ay:

• Pagkakahiwalay ng code (maaaring i-execute ngunit hindi mababasa mula sa EVM) at data (maaaring basahin ngunit hindi ma-e-execute)
• Ipinagbabawal ang dynamic jumps, tanging static jumps lamang ang pinapayagan
• Hindi na maaaring makita ng EVM code ang impormasyon na may kaugnayan sa gas
• Pagdagdag ng bagong explicit na subroutine mechanism

Istraktura ng EOF code

Splurge: Mga Pagpapabuti sa EVM (Karugtong)

Mananatili at maaaring lumikha ng mga lumang kontrata, kahit na sa huli ay maaaring i-phase out ang mga ito (o kahit pilitin na i-convert sa EOF code). Ang mga bagong kontrata ay makikinabang sa efficiency na dala ng EOF—una, sa pamamagitan ng bahagyang mas maliit na bytecode dahil sa subroutine feature, at kasunod nito ay mga bagong function o mas mababang gas cost na partikular sa EOF.

Pagkatapos maipakilala ang EOF, mas madali nang mag-upgrade, at ang pinaka-debelop na ngayon ay ang EVM Modular Arithmetic eXtension (EVM-MAX). Ang EVM-MAX ay lumilikha ng hanay ng mga bagong operasyon na partikular sa modular arithmetic at inilalagay ang mga ito sa bagong memory space na hindi ma-access ng ibang opcode, na nagpapahintulot sa mga optimization gaya ng Montgomery multiplication.

Isang mas bagong ideya ay ang pagsasama ng EVM-MAX at Single Instruction Multiple Data (SIMD) feature. Ang SIMD bilang isang konsepto sa Ethereum ay matagal nang umiiral, unang iminungkahi ni Greg Colvin sa EIP-616. Maaaring gamitin ang SIMD upang pabilisin ang maraming uri ng cryptography, kabilang ang hash functions, 32-bit STARKs, at lattice-based cryptography. Ang kombinasyon ng EVM-MAX at SIMD ay natural na magkasama para sa performance-oriented na pagpapalawak.

Ang isang pinagsamang disenyo ng EIP ay magsisimula sa EIP-6690, pagkatapos ay:

• Pahintulutan ang (i) anumang odd number o (ii) anumang power of 2 hanggang 2768 bilang modulus
• Para sa bawat EVM-MAX opcode (addition, subtraction, multiplication), magdagdag ng bersyon na hindi na gumagamit ng 3 immediate na x, y, z, kundi 7 immediate: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. Sa Python code, ganito ang magiging epekto ng mga opcode na ito:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

Sa aktwal na implementasyon, ito ay ipoproseso nang parallel.

• Maaaring magdagdag ng XOR, AND, OR, NOT at SHIFT (kabilang ang circular at non-circular), kahit man lang para sa power-of-2 modulus. Kasabay nito, magdagdag ng ISZERO (na magpu-push ng output sa EVM main stack), na sapat na malakas upang magpatupad ng elliptic curve cryptography, small field cryptography (tulad ng Poseidon, Circle STARKs), tradisyonal na hash functions (tulad ng SHA256, KECCAK, BLAKE), at lattice-based cryptography. Maaaring may iba pang EVM upgrades, ngunit sa ngayon ay mababa ang atensyon dito.

Mga Umiiral na Link ng Pananaliksik

• EOF: 
• EVM-MAX: 
• SIMD: 

Mga Natitirang Gawain at Trade-off

Sa kasalukuyan, planong isama ang EOF sa susunod na hard fork. Bagaman laging posible na alisin ito sa huling sandali—may mga feature na tinanggal sa mga nakaraang hard fork—ngunit magiging mahirap ito. Ang pagtanggal ng EOF ay nangangahulugan na ang anumang susunod na upgrade sa EVM ay kailangang gawin nang walang EOF, na maaaring gawin ngunit mas mahirap.

Ang pangunahing trade-off ng EVM ay ang L1 complexity laban sa infrastructure complexity. Ang EOF ay nangangailangan ng maraming code na idagdag sa EVM implementation, at ang static code checking ay medyo komplikado. Gayunpaman, kapalit nito, maaari nating gawing simple ang high-level na wika, gawing simple ang EVM implementation, at iba pang benepisyo. Maaaring sabihin na ang roadmap na inuuna ang patuloy na pagpapabuti ng Ethereum L1 ay dapat isama at itayo sa ibabaw ng EOF.

Isang mahalagang gawain ay ang magpatupad ng mga feature na katulad ng EVM-MAX plus SIMD, at mag-benchmark ng gas consumption para sa iba't ibang cryptographic operations.

Paano ito nakikipag-interact sa iba pang bahagi ng roadmap?

Ang pag-aadjust ng L1 sa EVM nito ay nagpapadali rin sa L2 na mag-adjust nang naaayon. Kung hindi sabay na mag-aadjust ang dalawa, maaaring magdulot ito ng incompatibility at negatibong epekto. Bukod dito, ang EVM-MAX at SIMD ay maaaring magpababa ng gas cost ng maraming proof system, kaya mas magiging efficient ang L2. Pinapadali rin nito ang pagpapalit ng mas maraming precompiles ng EVM code na kayang gawin ang parehong gawain, nang hindi gaanong naapektuhan ang efficiency.

Account Abstraction

Anong problema ang nalutas?

Sa kasalukuyan, tanging isang paraan lang ang maaaring gamitin para i-verify ang mga transaksyon: ECDSA signature. Sa simula, layunin ng account abstraction na lampasan ito, at pahintulutan ang account verification logic na maging arbitrary EVM code. Maaari nitong paganahin ang iba't ibang aplikasyon:

• Paglipat sa quantum-resistant cryptography
• Pag-rotate ng lumang mga key (malawakang inirerekomenda bilang security practice)
• Multi-signature wallets at social recovery wallets
• Paggamit ng isang key para sa low-value operations, at ibang key (o set ng mga key) para sa high-value operations

Pahintulutan ang privacy protocols na gumana nang walang relayer, na lubos na nagpapababa ng kanilang complexity at nag-aalis ng isang mahalagang central dependency

Mula nang ipanukala ang account abstraction noong 2015, lumawak din ang layunin nito upang isama ang maraming "convenience goals", halimbawa, ang isang account na walang ETH ngunit may ilang ERC20 ay maaaring gumamit ng ERC20 para magbayad ng gas. Narito ang isang summary chart ng mga layuning ito:

Ang MPC (multi-party computation) ay isang teknolohiyang may 40 taon nang kasaysayan, na ginagamit upang hatiin ang key sa maraming bahagi at i-store sa iba't ibang device, gamit ang cryptographic techniques upang bumuo ng signature nang hindi kailangang pagsamahin ang mga bahagi ng key.

Ang EIP-7702 ay isang proposal na planong isama sa susunod na hard fork. Ang EIP-7702 ay resulta ng lumalaking pagkilala sa pangangailangang magbigay ng account abstraction convenience para sa lahat ng user (kabilang ang EOA users), na layuning mapabuti ang experience ng lahat ng user sa maikling panahon at maiwasan ang pagkakahati sa dalawang ecosystem.

Nagsimula ang gawaing ito sa EIP-3074, at sa huli ay naging EIP-7702. Ang EIP-7702 ay nagbibigay ng "convenience features" ng account abstraction sa lahat ng user, kabilang ang mga EOA (externally owned accounts, ibig sabihin ay mga account na kontrolado ng ECDSA signature).

Mula sa chart, makikita na bagaman ang ilang hamon (lalo na ang "convenience" challenges) ay maaaring lutasin sa pamamagitan ng incremental na teknolohiya tulad ng multi-party computation o EIP-7702, ang pangunahing security goals na dahilan ng orihinal na account abstraction proposal ay maaari lamang makamit sa pamamagitan ng pagbalik at paglutas ng orihinal na problema: pahintulutan ang smart contract code na kontrolin ang transaction verification. Hanggang ngayon, hindi pa ito naisasakatuparan dahil sa hamon ng ligtas na implementasyon.

Ano ito at paano ito gumagana?

Ang core ng account abstraction ay simple: pahintulutan ang smart contracts na mag-initiate ng transactions, hindi lang EOA. Ang buong complexity ay nagmumula sa kung paano ito ipapatupad sa paraang friendly sa decentralized network at protektado laban sa denial-of-service attacks.

Isang tipikal na pangunahing hamon ay ang multi-invalidation problem:

Kung may 1000 accounts na ang verification function ay umaasa sa isang value S, at ang kasalukuyang value S ay nagpapahintulot sa mga transaction sa mempool na maging valid, isang transaction na magbabago sa value ng S ay maaaring mag-invalidate ng lahat ng ibang transaction sa mempool. Pinapayagan nito ang attacker na magpadala ng spam transactions sa mempool sa napakababang halaga, na nagbabara sa resources ng network nodes.

Matapos ang maraming taon ng pagsisikap upang palawakin ang functionality habang nililimitahan ang DoS risk, sa wakas ay nahanap ang solusyon para sa "ideal account abstraction": ERC-4337.

Ang ERC-4337 ay gumagana sa pamamagitan ng paghahati ng user operation processing sa dalawang yugto: verification at execution. Lahat ng verification ay unang pinoproseso, at lahat ng execution ay kasunod. Sa mempool, tanging ang user operations na ang verification phase ay tumutukoy lamang sa sariling account at hindi nagbabasa ng environmental variables ang tatanggapin. Pinipigilan nito ang multi-invalidation attacks. Bukod dito, may mahigpit na gas limit sa verification step.

Ang ERC-4337 ay idinisenyo bilang isang karagdagang protocol standard (ERC), dahil noong panahong iyon, nakatutok ang mga Ethereum client developer sa Merge at walang dagdag na resources para sa ibang features. Kaya, gumagamit ang ERC-4337 ng tinatawag na user operations, hindi regular na transactions. Gayunpaman, kamakailan ay napagtanto na kailangan nang isulat ang ilan sa mga ito sa protocol mismo.

Dalawang pangunahing dahilan:

1. Ang inherent inefficiency ng EntryPoint bilang contract: may fixed overhead na mga 100,000 gas bawat bundle, at ilang libong gas pa bawat user operation.
2. Pangangailangan na tiyakin ang Ethereum properties: tulad ng inclusion guarantees na nilikha ng inclusion list, na kailangang ilipat sa account abstraction users.

Bukod dito, pinalawak ng ERC-4337 ang dalawang features:

• Paymasters: nagpapahintulot sa isang account na magbayad ng fees para sa ibang account, na lumalabag sa rule na dapat lang ma-access ng verification phase ang sender account, kaya may special handling para matiyak ang security ng paymaster mechanism.
• Aggregators: sumusuporta sa signature aggregation, tulad ng BLS aggregation o SNARK-based aggregation. Ito ay mahalaga para sa pinakamataas na data efficiency sa Rollup.

Mga Umiiral na Link ng Pananaliksik

• Talumpati tungkol sa kasaysayan ng account abstraction:
• ERC-4337:
• EIP-7702:
• BLSWallet code (gamit ang aggregation feature):
• EIP-7562 (account abstraction na isinulat sa protocol):
• EIP-7701 (account abstraction na isinulat sa protocol batay sa EOF):

Mga Natitirang Gawain at Trade-off

Sa kasalukuyan, ang pangunahing kailangang lutasin ay kung paano ganap na isama ang account abstraction sa protocol. Ang pinakabagong popular na write-protocol account abstraction EIP ay EIP-7701, na nag-iimplement ng account abstraction sa ibabaw ng EOF. Ang isang account ay maaaring magkaroon ng hiwalay na code section para sa verification, at kung naka-set ito, ang code na ito ay ie-execute sa verification step ng transactions mula sa account na iyon.

Ang kagandahan ng pamamaraang ito ay malinaw nitong ipinapakita ang dalawang magkatumbas na pananaw ng native account abstraction:

1. Gawing bahagi ng protocol ang EIP-4337
2. Isang bagong uri ng EOA, kung saan ang signature algorithm ay ang execution ng EVM code

Kung magsisimula tayo sa mahigpit na limitasyon sa complexity ng executable code sa verification—hindi pinapayagan ang access sa external state, at kahit ang gas limit ay napakababa para sa quantum resistance o privacy applications—napakalinaw ng security ng pamamaraang ito: simpleng pinapalitan lang ang ECDSA verification ng EVM code execution na may katulad na tagal.

Gayunpaman, sa paglipas ng panahon, kailangan nating paluwagin ang mga limitasyong ito, dahil napakahalaga ng privacy applications na gumagana nang walang relayer at quantum resistance. Para dito, kailangan nating makahanap ng mas flexible na paraan upang lutasin ang DoS risk, nang hindi kinakailangang gawing sobrang simple ang verification step.

Ang pangunahing trade-off ay tila "mabilis na magsulat ng solusyon na mas kaunti ang nasisiyahan" laban sa "maghintay ng mas matagal para sa mas ideal na solusyon", at maaaring ang ideal na paraan ay isang hybrid approach. Ang isang hybrid approach ay ang mas mabilis na isulat ang ilang use cases, at maglaan ng mas maraming oras para tuklasin ang iba pang use cases. Ang isa pang paraan ay mag-deploy muna ng mas ambisyosong bersyon ng account abstraction sa L2. Gayunpaman, ang hamon dito ay dapat kumpiyansa ang L2 teams sa proposal para magpatupad, lalo na upang matiyak na ang L1 at/o ibang L2 ay maaaring magpatupad ng compatible na scheme sa hinaharap.

Kailangan din nating isaalang-alang ang isa pang application: key storage accounts, na nag-i-store ng account-related state sa L1 o dedicated L2, ngunit maaaring gamitin sa L1 at anumang compatible na L2. Para magawa ito nang epektibo, maaaring kailanganin ng L2 na suportahan ang mga opcode tulad ng L1SLOAD o REMOTESTATICCALL, ngunit nangangailangan din ito ng suporta mula sa L2 account abstraction implementation.

Paano ito nakikipag-interact sa iba pang bahagi ng roadmap?

Kailangan ng inclusion list na suportahan ang account abstraction transactions. Sa praktika, halos magkapareho ang pangangailangan ng inclusion list at decentralized mempool, bagaman mas flexible ang inclusion list. Bukod dito, dapat hangga't maaari ay mag-coordinate ang account abstraction implementation sa pagitan ng L1 at L2. Kung sa hinaharap ay inaasahan nating karamihan ng user ay gagamit ng key storage rollup, dapat nakabase dito ang disenyo ng account abstraction.

EIP-1559 Improvements

Anong problema ang nalutas?

Na-activate ang EIP-1559 sa Ethereum noong 2021, at malaki ang naitulong nito sa average block inclusion time.

Oras ng paghihintay

Gayunpaman, ang kasalukuyang implementasyon ng EIP-1559 ay hindi perpekto sa ilang aspeto:

1. Bahagyang may depekto ang formula: hindi ito target ang 50% ng blocks, kundi mga 50-53% full blocks, depende sa variance (kaugnay ito ng "arithmetic-geometric mean inequality" sa matematika).
2. Hindi sapat ang bilis ng adjustment sa extreme cases.

Ang formula na ginamit para sa blobs (EIP-4844) ay partikular na idinisenyo upang lutasin ang unang problema, at mas simple rin ito. Gayunpaman, hindi tinangka ng EIP-1559 at EIP-4844 na lutasin ang ikalawang problema. Kaya, ang kasalukuyang estado ay isang magulong gitnang kalagayan, na may dalawang magkaibang mekanismo, at may pananaw na sa paglipas ng panahon, parehong kailangang mapabuti.

Bukod dito, may iba pang kahinaan sa resource pricing ng Ethereum na hindi direktang kaugnay ng EIP-1559, ngunit maaaring lutasin sa pamamagitan ng pag-aadjust sa EIP-1559. Isa sa mga pangunahing problema ay ang pagkakaiba ng average at worst case: kailangang itakda ang resource price ng Ethereum para sa worst case (isang block na puno ng gas consumption ng isang resource), ngunit ang average na paggamit ay mas mababa, kaya nagiging inefficient.

Ano ang multi-dimensional Gas at paano ito gumagana?

Ang solusyon sa mga inefficiency na ito ay multi-dimensional Gas: magtakda ng iba't ibang presyo at limit para sa iba't ibang resources. Ang konseptong ito ay technically independent sa EIP-1559, ngunit pinadadali ng EIP-1559 ang implementasyon nito. Kung walang EIP-1559, ang optimal na pag-pack ng block na may maraming resource constraints ay isang komplikadong multi-dimensional knapsack problem. Ngunit sa EIP-1559, karamihan ng blocks ay hindi umaabot sa full capacity ng anumang resource, kaya sapat na ang simpleng algorithm na "tanggapin ang anumang transaction na nagbabayad ng sapat na fee".

Sa ngayon, mayroon na tayong multi-dimensional Gas para sa execution at data blobs; sa prinsipyo, maaari pa itong palawakin sa mas maraming dimension: tulad ng calldata (transaction data), state read/write, at state size expansion.

Ang EIP-7706 ay nag-iintroduce ng bagong gas dimension para sa calldata. Kasabay nito, pinapasimple nito ang multi-dimensional Gas mechanism sa pamamagitan ng pag-unify ng tatlong uri ng gas sa isang (EIP-4844 style) framework, na nilulutas din ang mathematical defect ng EIP-1559. Ang EIP-7623 ay mas precise na solusyon na tumutukoy sa average at worst case resource problem, mas mahigpit na nililimitahan ang maximum calldata nang hindi nagdadagdag ng bagong dimension.

Isang karagdagang direksyon ng pananaliksik ay ang paglutas ng update rate problem, paghahanap ng mas mabilis na base fee calculation algorithm habang pinapanatili ang pangunahing invariants na ipinakilala ng EIP-4844 mechanism (ibig sabihin: sa pangmatagalan, ang average usage ay eksaktong malapit sa target value).

Mga Umiiral na Link ng Pananaliksik

• EIP-1559 FAQ: 
• Empirical analysis ng EIP-1559: 
• Mga proposal para sa mabilis na adjustment: 
• Bahagi ng EIP-4844 FAQ tungkol sa base fee mechanism: 
• EIP-7706: 
• EIP-7623: 
• Multi-dimensional Gas: 

Ano ang natitirang gawain at trade-off?

May dalawang pangunahing trade-off ang multi-dimensional Gas:

1. Pagdagdag ng protocol complexity: Ang pag-introduce ng multi-dimensional Gas ay nagpapakomplikado sa protocol.
2. Pagdagdag ng complexity ng optimal algorithm para sa pagpuno ng block: Mas magiging komplikado ang optimal algorithm para mapuno ang block sa capacity.

Ang protocol complexity ay maliit lang para sa calldata, ngunit para sa mga Gas dimension sa loob ng EVM (tulad ng storage read at write), mas tumataas ang complexity. Ang problema ay hindi lang user ang nagse-set ng gas limit, kundi pati ang contract kapag tumatawag sa ibang contract. Sa ngayon, isang dimension lang ang maaaring i-set.

Isang simpleng solusyon ay gawing available lang ang multi-dimensional Gas sa loob ng EOF, dahil hindi pinapayagan ng EOF ang contract na mag-set ng gas limit kapag tumatawag sa ibang contract. Ang non-EOF contracts ay kailangang magbayad ng lahat ng uri ng Gas fees kapag gumagawa ng storage operations (halimbawa, kung ang SLOAD ay gumagamit ng 0.03% ng block storage access gas limit, ang non-EOF user ay sisingilin din ng 0.03% ng execution gas limit fee).

Ang karagdagang pananaliksik sa multi-dimensional Gas ay makakatulong upang maunawaan ang mga trade-off na ito at mahanap ang ideal na balanse.

Paano ito nakikipag-interact sa iba pang bahagi ng roadmap?

Ang matagumpay na implementasyon ng multi-dimensional Gas ay maaaring lubos na magpababa ng ilang "worst case" resource usage, kaya mababawasan ang pressure na mag-optimize ng performance para sa mga pangangailangan tulad ng STARKed hash-based binary trees. Ang pagtatakda ng malinaw na target para sa state size growth ay magpapadali sa client developers na magplano at mag-estimate ng requirements sa hinaharap.

Tulad ng nabanggit, pinadadali ng pagkakaroon ng EOF ang implementasyon ng mas extreme na bersyon ng multi-dimensional Gas, dahil sa gas unobservability nito.

Verifiable Delay Functions (VDFs)

Anong problema ang nalutas?

Sa kasalukuyan, gumagamit ang Ethereum ng RANDAO-based randomness para pumili ng proposer. Ang randomness ng RANDAO ay gumagana sa pamamagitan ng pag-reveal ng bawat proposer ng kanilang pre-committed secret, at pag-mix ng bawat secret sa randomness.

Bawat proposer ay may "1 bit ng control": maaari nilang baguhin ang randomness sa pamamagitan ng hindi pagpakita (may cost ito). Ang pamamaraang ito ay reasonable para sa proposer selection, dahil bihira ang pagkakataon na mag-give up ng isang chance para makakuha ng dalawa. Ngunit para sa mga on-chain application na nangangailangan ng randomness, hindi ito ideal. Sa ideal na kalagayan, dapat tayong makahanap ng mas robust na randomness source.

Ano ang VDF at paano ito gumagana?

Ang verifiable delay function ay isang function na maaari lang i-compute nang sunud-sunod at hindi mapapabilis sa pamamagitan ng parallelization. Isang simpleng halimbawa ay repeated hashing: for i in range(10**9): x = hash(x). Ang output, na may SNARK proof ng correctness, ay maaaring gamitin bilang random value.

Ang ideya ay pumili ng input batay sa impormasyong available sa oras na T, ngunit hindi pa alam ang output sa oras na T: ang output ay lalabas lang pagkatapos ng computation. Dahil kahit sino ay maaaring magpatakbo ng computation, walang paraan para itago ang resulta, kaya walang paraan para i-manipulate ito.

Ang pangunahing panganib ng VDF ay ang hindi inaasahang optimization: may makakahanap ng paraan para patakbuhin ang function nang mas mabilis kaysa sa inaasahan, at manipulahin ang impormasyong ire-reveal sa oras na T.

Maaaring mangyari ang hindi inaasahang optimization sa dalawang paraan:

1. Hardware acceleration: may gagawa ng ASIC na mas mabilis kaysa sa kasalukuyang hardware para sa computation loop.
2. Hindi inaasahang parallelization: may makakahanap ng paraan para i-parallelize ang function at patakbuhin ito nang mas mabilis, kahit na kailangan ng 100x na resources.

Ang paggawa ng matagumpay na VDF ay nangangahulugan ng pag-iwas sa dalawang problemang ito, habang pinapanatili ang practicality (halimbawa, ang SNARK proof ng real-time hashing ay nangangailangan ng heavy hardware). Karaniwang nilulutas ang hardware acceleration sa pamamagitan ng public interest participant na gumagawa at nagdi-distribute ng near-optimal VDF ASIC.

Mga Umiiral na Link ng Pananaliksik

• VDF research website: 
• Pag-iisip tungkol sa VDF attacks sa Ethereum, 2018: 
• Attack sa proposed VDF MinRoot: 

Ano ang natitirang gawain at trade-off?

Sa kasalukuyan, wala pang VDF construction na ganap na nakakatugon sa lahat ng pangangailangan ng Ethereum researchers. Kailangan pa ng karagdagang trabaho upang makahanap ng ganoong function. Kung matagpuan, ang pangunahing trade-off ay kung isasama ito: simpleng trade-off ng functionality laban sa protocol complexity at security risk.

Kung sa tingin natin ay ligtas ang VDF ngunit sa huli ay hindi pala, depende sa implementasyon, babagsak ang security sa RANDAO assumption (1 bit ng control bawat attacker) o bahagyang mas masama. Kaya, kahit mabigo ang VDF, hindi masisira ang protocol, ngunit maaapektuhan ang mga application o bagong protocol features na malakas na umaasa rito.

Paano ito nakikipag-interact sa iba pang bahagi ng roadmap?

Ang VDF ay isang medyo self-contained na bahagi ng Ethereum protocol. Bukod sa pagdagdag ng security sa proposer selection, may application din ito sa (i) mga on-chain application na nangangailangan ng randomness at (ii) encrypted mempools, bagaman ang paggawa ng encrypted mempools gamit ang VDF ay umaasa pa rin sa karagdagang cryptographic discoveries na hindi pa nangyayari.

Isang bagay na dapat tandaan ay, dahil sa hardware uncertainty, magkakaroon ng "slack" sa pagitan ng VDF output generation at pangangailangan. Ibig sabihin, magiging available ang impormasyon ilang blocks bago ito kailanganin. Maaaring tanggapin ito bilang cost, ngunit dapat isaalang-alang sa single-slot finality o committee selection design.

Obfuscation at One-shot Signatures: Ang Malayong Hinaharap ng Cryptography

Anong problema ang nalutas?

Isa sa pinakakilalang artikulo ni Nick Szabo ay ang kanyang 1997 na sanaysay tungkol sa "God Protocol". Sa artikulong ito, binanggit niya na maraming multi-party applications ang umaasa sa "trusted third party" para pamahalaan ang interaction. Sa kanyang pananaw, ang papel ng cryptography ay lumikha ng simulated trusted third party na gumagawa ng parehong trabaho, nang hindi talaga nangangailangan ng tiwala sa sinumang participant.

Sa ngayon, bahagya pa lang nating naisasakatuparan ang ideal na ito. Kung ang kailangan lang natin ay isang transparent virtual computer na hindi maaaring patayin, i-censor, o baguhin ang data at computation, at hindi layunin ang privacy, maaaring magawa ito ng blockchain, kahit na limitado ang scalability.

Kung privacy ang layunin, hanggang kamakailan, tanging mga partikular na protocol para sa bawat application ang magagawa: digital signatures para sa basic authentication, ring signatures at linkable ring signatures para sa raw anonymity, identity-based encryption para sa mas convenient na encryption sa ilalim ng trusted issuer assumption, at blind signatures para sa Chaumian e-cash, atbp. Nangangailangan ito ng maraming trabaho para sa bawat bagong application.

Noong 2010s, unang nakita natin ang mas malakas na paraan batay sa programmable cryptography. Sa halip na gumawa ng bagong protocol para sa bawat application, maaari nating gamitin ang mga makapangyarihang bagong protocol—lalo na ang ZK-SNARKs—para magdagdag ng cryptographic guarantees sa anumang program.

Pinapayagan ng ZK-SNARKs ang user na patunayan ang anumang pahayag tungkol sa data na hawak nila, at ang proof ay (i) madaling i-verify, at (ii) hindi naglalabas ng anumang impormasyon maliban sa mismong pahayag. Ito ay malaking hakbang sa privacy at scalability, at inihahalintulad ko ito sa epekto ng transformers sa AI. Libo-libong taon ng application-specific na trabaho ang biglang napalitan ng isang general-purpose solution na kayang hawakan ang napakalawak na problema.

Gayunpaman, ang ZK-SNARKs ay isa lamang sa tatlong napakalakas na general-purpose primitives. Ang mga protocol na ito ay napakalakas na kapag naiisip ko sila, naaalala ko ang isang set ng napakalakas na card sa Yu-Gi-Oh!—ang Egyptian God Cards.

Ang Egyptian God Cards ay tatlong napakalakas na card, na ayon sa alamat ay maaaring nakamamatay ang paggawa, at ipinagbabawal gamitin sa duels dahil sa lakas. Sa cryptography, mayroon din tayong tatlong Egyptian God Protocols:

Ano ang ZK-SNARKs at paano ito gumagana?

Ang ZK-SNARKs ay isa sa tatlong protocol na mayroon na tayo, at medyo mature na. Sa nakaraang limang taon, ang bilis ng prover at developer-friendliness ay lubos na bumuti, kaya naging pundasyon ito ng Ethereum scalability at privacy strategy. Ngunit may mahalagang limitasyon ang ZK-SNARKs: kailangan mong malaman ang data para mapatunayan ito. Sa bawat ZK-SNARK application, dapat may unique na "owner" ng state na kailangang naroon para aprubahan ang pagbabasa o pagsusulat sa state.

Ang pangalawang protocol na walang limitasyong ito ay Fully Homomorphic Encryption (FHE), na nagpapahintulot sa computation sa encrypted data nang hindi ito tinitingnan. Pinapayagan nito ang computation sa user data para sa kanilang kapakinabangan, habang pinananatiling pribado ang data at algorithm.

Pinapayagan din nitong i-extend ang mga voting system tulad ng MACI para makamit ang halos perpektong security at privacy guarantees. Matagal nang itinuturing na masyadong mabagal ang FHE para sa praktikal na paggamit, ngunit ngayon ay sapat na itong mabilis para magkaroon ng aktwal na aplikasyon.

Ang Cursive ay isang application na gumagamit ng two-party computation at FHE para sa privacy-preserving mutual interest discovery.

Gayunpaman, may limitasyon din ang FHE: anumang FHE-based na teknolohiya ay nangangailangan pa rin ng isang tao na may hawak ng decryption key. Maaari itong maging distributed M-of-N setup, o gumamit ng TEEs para sa dagdag na proteksyon, ngunit limitasyon pa rin ito.

Ang susunod ay ang pangatlong protocol, na mas malakas pa kaysa sa kombinasyon ng nauna: indistinguishability obfuscation. Bagaman malayo pa ito sa maturity, mula 2020 ay mayroon na tayong theoretically valid protocol batay sa standard security assumptions, at kamakailan ay sinimulan na rin ang implementasyon.

Pinapayagan ng indistinguishability obfuscation na gumawa ng "encrypted program" na gumagawa ng anumang computation habang tinatago ang lahat ng internal details ng program. Halimbawa, maaari mong ilagay ang private key sa obfuscated program na pinapayagan lang ang pag-sign ng primes, at ipamahagi ito. Maaari nilang gamitin ito para mag-sign ng anumang prime, ngunit hindi makukuha ang key. Ngunit higit pa rito: sa kombinasyon ng hash, maaari nitong ipatupad ang anumang cryptographic primitive at higit pa.

Ang tanging hindi kayang gawin ng obfuscated program ay pigilan ang sarili nitong makopya. Ngunit para dito, may mas malakas pang teknolohiya na naghihintay, bagaman nangangailangan ito na lahat ay may quantum computer: quantum one-shot signatures.

Sa pagsasama ng obfuscation at one-shot signatures, maaari tayong bumuo ng halos perpektong trustless third party. Ang tanging hindi kayang gawin ng cryptography ay ang censorship resistance, na kailangan pa rin ng blockchain. Ang mga teknolohiyang ito ay hindi lang magpapalakas sa Ethereum, kundi pati sa mga application na itatayo rito.

Para mas maunawaan kung paano nagbibigay ng dagdag na kakayahan ang mga primitives na ito, gamitin natin ang voting bilang pangunahing halimbawa. Ang voting ay isang interesting na problema dahil nangangailangan ito ng maraming complex security properties, kabilang ang napakalakas na verifiability at privacy. Bagaman may mga voting protocol na may malakas na security properties sa loob ng dekada, maaari nating gawing mas mahirap ang problema at idisenyo ito para sa arbitrary voting protocol: quadratic voting, pairwise-constrained quadratic funding, clustered quadratic funding, atbp. Sa madaling salita, gusto natin na ang "counting" step ay arbitrary program.

Una, ipagpalagay nating ilalagay natin ang voting result sa blockchain. Nagbibigay ito ng public verifiability (kahit sino ay maaaring mag-verify ng final result, kabilang ang counting at eligibility rules) at censorship resistance (hindi maaaring pigilan ang pagboto). Ngunit walang privacy.

Pagkatapos, magdagdag tayo ng ZK-SNARKs, at ngayon, may privacy na: bawat boto ay anonymous, habang tinitiyak na tanging authorized voters lang ang makakaboto at isang boto lang bawat tao.

Susunod, magdagdag tayo ng MACI mechanism, kung saan ang mga boto ay encrypted para sa central server na may decryption key. Ang central server ang nagbibilang ng boto, kabilang ang pagtanggal ng duplicate votes, at naglalabas ng ZK-SNARK proof ng resulta. Pinapanatili nito ang mga dating guarantee (kahit mag-cheat ang server!), ngunit kung honest ang server, nadaragdagan pa ng coercion resistance: hindi mapapatunayan ng user ang kanilang boto kahit gusto nila. Dahil kahit mapatunayan ng user ang kanilang boto, hindi nila mapapatunayan na hindi sila bumoto para i-offset ito. Pinipigilan nito ang bribery at iba pang attacks.

Patakbuhin natin ang counting sa FHE, at gawin ang N/2-of-N threshold decryption. Pinapataas nito ang coercion resistance sa N/2-of-N, hindi lang 1-of-1.

I-obfuscate natin ang counting program, at idisenyo ito para mag-output lang ng result kapag may authorization, na maaaring proof ng blockchain consensus, proof-of-work, o kombinasyon. Pinapabuti nito ang coercion resistance: sa blockchain consensus, kailangan ng 51% ng validators para mag-break; sa proof-of-work, kahit mag-collude lahat, napakamahal ng pag-recount gamit ang ibang subset ng voters para subukang i-extract ang behavior ng isang voter. Maaari pa nating gawing random ang final result para mas mahirapan pang i-extract ang behavior ng isang voter.

Magdagdag tayo ng one-shot signatures, isang quantum primitive na nagpapahintulot ng signature para lang sa isang partikular na uri ng impormasyon. Ginagawa nitong tunay na perpekto ang coercion resistance.

Sinusuportahan din ng indistinguishability obfuscation ang iba pang malalakas na application. Halimbawa:

1. DAOs, on-chain auctions, at iba pang application na may arbitrary internal secret state.
2. Tunay na universal trusted setup: maaaring gumawa ang isang tao ng obfuscated program na may key, at patakbuhin ang anumang program at magbigay ng output, gamit ang hash(key, program) bilang input. Sa ganitong program, maaaring maglagay ng program 3 sa sarili nito, pagsamahin ang pre-key ng program at sariling key, at palawakin ang setup. Maaari itong gamitin para gumawa ng 1-of-N trusted setup para sa anumang protocol.
3. ZK-SNARK verification na nangangailangan lang ng isang signature: napakadaling gawin ito—mag-set up ng trusted environment, gumawa ng obfuscated program na mag-sign lang ng message gamit ang key kapag valid ang ZK-SNARK.
4. Encrypted mempool: napakadaling mag-encrypt ng transactions para ma-decrypt lang kapag may nangyaring on-chain event sa hinaharap. Maaari pa itong isama ang successful execution ng VDF.

Sa tulong ng one-shot signatures, maaari nating gawing immune ang blockchain sa 51% finality reversion attacks, bagaman maaari pa ring mangyari ang censorship attacks. Ang mga primitive na tulad ng one-shot signatures ay nagpapahintulot ng quantum money, na nilulutas ang double-spending problem nang walang blockchain, bagaman maraming mas kumplikadong application ang nangangailangan pa rin ng chain.

Kung magiging sapat na efficient ang mga primitive na ito, karamihan ng application sa mundo ay maaaring gawing decentralized. Ang pangunahing bottleneck ay ang pag-verify ng tamang implementasyon.

Narito ang ilang umiiral na link ng pananaliksik:

• Indistinguishability obfuscation protocol (2021): 
• Paano makakatulong ang obfuscation sa Ethereum: 
• Unang kilalang one-shot signature construction: 
• Pagsubok na implementasyon ng obfuscation (1): 
• Pagsubok na implementasyon ng obfuscation (2): 

Ano pa ang kailangang gawin at ano ang trade-off?

Marami pang kailangang gawin, at ang indistinguishability obfuscation ay napaka-immature pa. Ang mga candidate construction ay napakabagal (o higit pa), kaya hindi magagamit sa application. Kilala ang indistinguishability obfuscation sa "theoretical" polynomial time, ngunit sa praktika, maaaring mas matagal pa ito kaysa sa lifetime ng universe. Ang mga pinakabagong protocol ay mas mabilis, ngunit masyado pa ring mabagal para sa regular na paggamit: tinatayang isang taon ang runtime ng isang implementer.

Wala pa ring quantum computer: lahat ng nakikita mong construction online ay prototype na hindi kayang mag-compute ng higit sa 4 digits, o hindi talaga quantum computer, kahit may quantum component, hindi kayang patakbuhin ang meaningful computation tulad ng Shor o Grover algorithm. Kamakailan, may mga palatandaan na "tunay" na quantum computer ay malapit na. Ngunit kahit lumabas ito, maaaring abutin pa ng dekada bago magamit ng ordinaryong tao sa laptop o cellphone, bago dumating ang araw na kayang i-break ng malalaking institusyon ang elliptic curve cryptography.

Para sa indistinguishability obfuscation, isang mahalagang trade-off ay ang security assumptions, dahil may mas agresibong disenyo na gumagamit ng special assumptions. Karaniwan, mas mabilis ang mga ito, ngunit minsan ay nababasag ang special assumptions. Sa paglipas ng panahon, maaaring mas maunawaan natin ang lattice at makagawa ng assumptions na mahirap basagin. Ngunit mas risky ang landas na ito. Ang mas konserbatibong paraan ay manatili sa mga protocol na ang security ay maaaring i-reduce sa "standard" assumptions, ngunit maaaring mas matagal bago tayo magkaroon ng sapat na mabilis na protocol.

Paano ito nakikipag-interact sa iba pang bahagi ng roadmap?

Ang napakalakas na cryptography ay maaaring magbago ng laro, halimbawa:

1. Kung makakamit natin ang ZK-SNARK verification na kasing simple ng signature, maaaring hindi na kailanganin ang anumang aggregation protocol; maaaring direktang i-verify on-chain.
2. Maaaring magdulot ng mas secure na proof-of-stake protocol ang one-shot signatures.
3. Maraming kumplikadong privacy protocol ay maaaring palitan ng isang privacy-preserving EVM.
4. Mas madaling maipatupad ang encrypted mempool.

Sa simula, ang mga benepisyo ay lilitaw sa application layer, dahil kailangang maging konserbatibo ang Ethereum L1 sa security assumptions. Ngunit kahit application layer lang, maaaring maging disruptive ito, tulad ng nangyari sa pagdating ng ZK-SNARKs.