Babala ng Lido Engineer sa Panganib ng Pag-hijack ng Staking Deposit Habang Nagtatrabaho ang Ethereum sa Glamsterdam Transition

2026/10/21 14:09:00

Bakit Tinanggihan ng mga Developer ng Ethereum ang Paggawa ng Pagsasayos sa Level ng Protocol

Ang susunod na pangunahing pagpapalawig ng network ng ethereum ay naglalayong i-scale ang base layer sa pamamagitan ng enshrined proposer-builder separation at mas mataas na gas limits, ngunit isang vulnerability na may kinalaman sa oras ay nagdulot ng bagong pagmamasid mula sa isa sa mga pinakamalaking liquid staking provider. Noong Oktubre 20, 2026, si Dima Gusakov, Punong Inhinyero sa Lido Finance, ay pampublikong inilahad kung paano ang paglipat patungo sa Glamsterdam ay maaaring bigyan ng pagkakataon ang isang masasamang node operator na front-run ang validator deposit ng isang staker. Ang pag-atake ay gagamit ng builder deposits na may 0xB0-prefixed withdrawal credentials na nagbabahagi ng deposit queue nang pansamantala, na maaaring i-credit ang ETH sa isang builder account kesa sa pag-activate ng inaasahang validator. Ang panahon ay limitado lamang sa hard-fork transition mismo. Pagkatapos ng upgrade, maglalakbay ang builder deposits sa hiwalay na contract path.

Isinara ang isang proponadong pag-aayos sa antas ng protokolo sa mga spesipikasyon ng pagkakasundo bilang “hindi iskedyul,” na naglipat ng tanggol na bigat sa mga protokolo ng staking. Tinitiyak ng artikulong ito ang teknikal na mekanismo ng panganib, ang mga desisyon sa disenyo ng upgrade na naglikha ng pansamantalang pagkakasalungat, ang mga dahilan kung bakit tinanggihan ng mga pangunahing developer ang isang patch sa protokolo, ang praktikal na hakbang na dapat gawin ng mga provider ng liquid staking, ang testnet timeline na nagbibigay sa mga operator ng ilang araw lamang para maghanda, at ang mas malawak na aral para sa seguridad ng delegated staking habang unti-unting inaayos ng Ethereum ang kanilang roadmap para sa scaling. Batay lamang sa pagsasalaysay at pangunahing pahayag mula sa nakaraang 30 araw ang pagsusuri, na nakatuon sa mga napatunayang detalye kaysa sa spekulasyon.

Ang Lido Engineering Lead ay Naglalahad ng Front-Running Vector sa X at sa Developer Calls

Ibinigay ni Dima Gusakov ang babala noong Oktubre 20, 2026, na tumutok sa mga staking protocol at delegated stakers. Ipinaliwanag niya na maaaring sumumite ang isang node operator ng builder deposit gamit ang parehong public key bago makarating ang legitimate validator deposit transaction. Dahil sa Glamsterdam na naglalayong maglagay ng builder deposits na nakasalalay sa withdrawal credentials na may prefix na 0xB0, at dahil ang mga deposit na ito ay nagbabahagi ng validator deposit queue habang nasa transisyon, ang unang valid na deposit ang makakakuha ng mga pondo. Ang resulta ay ang validator ng staker ay hindi maiikli sa beacon chain habang ang ETH ay credit sa builder account ng attacker. Teknikal ni Gusakov na posibleng mangyari ang attack lamang sa panahon ng hard fork. Bago ang Glamsterdam, ang builder deposits ay lumalakbay sa umiiral na validator deposit queue; pagkatapos, ito ay rute sa isang dedicated contract. Ang limitadong tagal, ayon sa kanya, ay gumagawa ng feasible na mitigation para sa mga handang protocol.

Kinabiglang lumabas ang parehong pag-aalala sa All Core Devs Consensus call (ACDC #189). Ipinakita ni Gusakov na ang isang beses na mekanismo ng pag-onboard ng builder ng Glamsterdam ay maaaring magdulot ng pagkakaiba sa mga pattern ng pagprotekta sa deposito na matagal nang ginagamit ng mga staking protocol. Ayon sa kasalukuyang mga patakaran, ang unang wastong deposito para sa isang public key ay tumatakda ng withdrawal credentials nang permanenteng. Madalas ang mga protocol ay magdeposo muna ng maliit na amount, kumpirmahin kung lumalabas ang inaasahang credentials, at bago lamang ay idagdag ang natitirang balanse. Sa panahon ng fork transition, ang espesyal na onboarding path ay maaaring magdulot ng ikatlong resulta: walang validator ang aktibuhin, at ang buong deposito ay itinatala sa isang builder. Tinanggihan ng core developers ang isang huling pagbabago sa spesipikasyon na magpapanatili sa pagkakaiba sa pagitan ng validator at builder deposits sa isang beses na onboarding, dahil sa katotohanan na ang Sepolia ay naka-activate na sa ilalim ng umiiral na mga patakaran at ang mga release ng Hoodi client ay nasa paghahanda na. Ang pagbabago sa pag-uugali sa antas na iyon ay magdudulot ng kinakailangang muli nang i-deploy ang Sepolia at karagdagang mga cycle ng pagsubok.

Paano nag-uugnay ang 0xB0 Builder Credentials sa Shared Deposit Queue

Ipinakilala ng Glamsterdam ang builder deposits bilang bahagi ng paglipat patungo sa enshrined proposer-builder separation. Ang mga deposit na ito ay may withdrawal credentials na nagsisimula sa prefix na 0xB0, na nagpapakilala sa kanila mula sa karaniwang validator credentials. Sa panahon ng transisyon, ang dalawang uri ng deposit ay nagbabahagi ng parehong queue processing path. Ang isang node operator na may kontrol o kakayahan na impluwensyahan ang pagkakasunod-sunod ng pag-submit ng deposit ay maaaring mag-insert ng builder-credentialed deposit na tumutugma sa isang pending staker public key. Pagkatapos tanggapin ang unang deposit, ang network ay itinuturing ang public key bilang nakuha sa ilalim ng builder credentials. Ang mga susunod na deposit sa parehong key ay iiwasan para sa validator activation o irere-direct ayon sa mga bagong interpretasyon na magpapatakbo sa paligid ng fork boundary.

Ang praktikal na epekto ay ang staker ay nawawala ang inaasahang validator at ang i-deposit na ETH, na ngayon ay nasa ilalim ng kontrol ng builder. Ang mga umiiral na naka-activate na validator at mga nai-process na deposito ay nananatiling walang epekto. Ang panganib ay limitado sa mga bago o paunang nasa queue na deposito na lumalampas sa activation epoch. Dahil natatapos ang pagkakasama-isa sa queue kapag natapos na ang fork at lumipat ang builder deposits sa kanilang dedikadong contract, ang eksposur ay pansamantala. Ang pansamantalang katangian nito ang pangunahing dahilan kung bakit inasikaso ni Gusakov na huwag mag-panic habang hinihikayat ang bawat delegated staking service na ipatupad o palakasin ang pre-deposit verification bago ang mainnet activation.

Ipinagtapos ng mga Core Developer ang Consensus-Specs Proposal bilang Hindi Iskedyul

Ang teknikal na pag-uusap tungkol sa pag-aayos sa antas ng protocol ay lumabas sa isyu #5735 ng consensus-specs. Ang panukala ay nangangailangan ng mga pagsusuri bago mag-deposit na magpapatotoo sa ilang mga kondisyon bago tanggapin ang deposito sa queue. Pagkatapos ng pagsusuri, isinara ang isyu na may katayuan na “hindi iskedyul.” Ang desisyon ay nananatiling nag-iisip sa application layer bilang pagsisikap na magkaroon ng depensa, kaysa i-embed ang karagdagang mga pagsusuri sa core protocol. Kaya ang pampublikong gabay ni Gusakov ay nakatuon sa pagpapagana ng mga staking protocol ng kanilang sariling pre-deposit validation. Ang mga limitasyon sa oras ay malakas na naimpluwensyahan ang resulta. Ang Sepolia ay nangyari na ang fork sa ilalim ng umiiral na spesipikasyon noong Oktubre 6, 2026.

Ang mga paglabas ng Hoodi client ay umunlad patungo sa pag-activate noong Oktubre 26. Ang pagpapakilala ng isang huling pagbabago sa pag-uugali ay maaaring magdulot ng pag-redeploy sa Sepolia at karagdagang pagkaantala sa pagsubok. Tinukoy ng mga pangunahing developer na ang limitadong panahon at ang kakayahan ng mga koponan sa application-layer na magdagdag ng mga pagsusuri ay nagpapahiwatig na hindi kailangan ang isang protocol patch sa kasalukuyang yugto. Ang resulta ay isang distributed security model kung saan bawat liquid staking provider ay kailangang i-confirm na tama niyang natatangi o binabawal ang mga deposito na may prefix na 0xB0 na nagtatangkang mag-claim ng validator public keys.

Ang mga pag-check bago mag-deposit ay naging pangunahing depensa para sa mga serbisyo ng liquid staking

Ang Lido mismo ay nagpapatakbo ng Deposit Security Module at guardian committee mula noong unang makita ang mga vulnerability kaugnay sa deposit taon-taon. Ang mga guardian ay sinusuri ang deposit-root snapshots bago magproceed ang mga batch, at isang mag-isa lamang na honest na guardian ay maaaring i-pause ang mga deposit. Ang open question ay kung ang umiiral na infrastructure ay nagsasama na ng bagong 0xB0 credential type at ang pansamantalang shared-queue dynamics, o kung kailangan pa ng karagdagang logic para sa Glamsterdam transition. Ang iba pang mga protocol na walang katulad na multi-party oversight ay nakakaranas ng mas mahirap na paghahanda.

Ang mga pagsusuri bago mag-deposit ay maaaring magkaroon ng ilang konkretong anyo. Maaaring tumanggi ang isang protocol sa anumang pag-deposit kung ang mga detalye ng pag-withdraw ay nagsisimula sa 0xB0 kapag ang layunin ay ang standard na pag-activate ng validator. Maaari itong maghingi ng on-chain o off-chain na pagpapatotoo na ang public key ay hindi pa nakareklamo sa ilalim ng builder credentials. Maaari itong ipa-pause ang mga bagong pag-deposit sa isang maikling panahon na nakapalibot sa activation epoch hanggang sa matapos ang shared-queue period. Dahil ang attack surface ay umiiral lamang habang ang mga queue ay nagkakasabay, ang isang pansamantalang pag-pause o mas mataas na pagmamasid sa panahong iyon ay maaaring tanggalin ang karamihan sa praktikal na eksposur. Ang mas maliit o mas bagong staking services na hindi pa nabuo ang mga komite na estilo ng guardian ay kailangang mabilis mag-aksi kung kanilang intensyon na tanggapin ang mga pag-deposit sa pamamagitan ng mainnet transition.

Glamsterdam Activation Schedule Leaves Little Margin for Preparation

Kinumpirma ng Ethereum Foundation na mag-activate ang Glamsterdam sa Hoodi testnet sa epoch 132,352, slot 4,235,264, na tumutugma sa October 26, 2026, sa 17:42:48 UTC. Sa parehong epoch, tumataas ang gas limit ng Hoodi sa 200 milyon. Ang Sepolia ay naka-activate na noong October 6. Ang oras sa mainnet ay patuloy na hindi desidido, kasama ang mga posibleng petsa sa unang bahagi ng Disyembre na pinag-uusapan, na nakadepende sa malinis na Hoodi fork. Kaya mayroon lang silang ilang araw pagkatapos ng babala ni Gusakov para i-validate ang kanilang deposit pipelines sa Hoodi ang mga node operator at staking teams.

Ang mga koponan ng client ay nag-publish ng mga kompatibleng bersyon para sa parehong consensus at execution layers. Dapat i-upgrade ng mga operator ang parehong beacon nodes at validator client, suriin ang anumang pagbabago sa builder interfaces na ipinakilala ng enshrined proposer-builder separation, at tiyakin na ang logic ng deposit-submission ay tama ang paghawak ng bagong credential prefix. Ang maikling panahon sa pagitan ng pampublikong babala at ang unang pampublikong testnet activation ay nagpapakita kung bakit kailangan handa ang mga depensa sa application layer bago buksan ang mainnet transition window.

Ipinagkakaloob na Pagkakahiwalay ng Proposer at Builder ay Naglalabas ng Bagong Daanan para sa Pag-deposit

Ang Glamsterdam ay nagkakaisa ang mga pagbabago sa execution-layer ng Amsterdam at ang mga pagbabago sa consensus-layer ng Gloas. Ang dalawang pangunahing tampok nito ay ang enshrined proposer-builder separation (EIP-7732) at ang block-level access lists. Sa ilalim ng ePBS, ang mga builder ay nakarehistro sa-chain gamit ang kanilang sariling balanse at public keys, nagsumite ng mga tawag, at pagkatapos ay ipinapakita ang execution payloads. Ang protocol mismo ang nag-aalok ng pagbabayad sa proposer, na nagpapabawas sa pagkakasalalay sa mga external relay. Ang mga builder deposit at exit ay naging first-class execution requests, kaya lumalabas ang 0xB0 credential prefix at ang temporary queue overlap.

Ang disenyo ay nagpapabuti sa scalability sa pamamagitan ng pagbibigay ng higit pang oras sa mga validator upang prosesuhin ang mas malalaking payload at sa pagpapahintulot sa mas mataas na gas limits. Samantala, ito ay naglilikha ng bagong daan para sa mga builder na dapat nang maging maingat na hiwalayin mula sa karaniwang mga deposito ng validator. Ang mekanismo ng isang beses na paglipat ang pinagmulan ng pansamantalang kalituhan. Pagkatapos ang network ay ganap na lumipat, ang mga deposito ng builder ay lalakbay sa kanilang sariling contract, at nawawala ang panganib ng shared-queue. Kaya ang upgrade ay nagpapabuti sa mahabang panahong arkitektura habang nangangailangan ng pansamantalang pagiging alerto mula sa anumang serbisyo na nagpapadala ng mga deposito para sa mga user.

Ang nakaraang karanasan ni Lido sa seguridad ng pag-deposit ay nagbibigay-daan sa kasalukuyang tugon

Nakaranas ang Lido ng mga panganib na deposit front-running noong nakaraang taon at sumagot sa pamamagitan ng pagpapabatid ng Deposit Security Module kasama ang isang komite ng tagapag-ingat. Ang komite ay nagpapatotoo sa mga deposit-root snapshots; isang tagapag-ingat lamang ang makapag-trigger ng pagpause. Ang infrastrakturang ito ay napatunayan na magagamit sa iba pang operational na insidente. Ang kaso ng Glamsterdam ay sinusubok kung ang mga kontrol na ito ay tama ring nakikilala ang bagong uri ng credential at ang maikling panahon ng pagbabahagi ng queue.

Ang mga protokolo na nag-adopt ng katulad na multi-signature o guardian patterns pagkatapos ng mga nakaraang insidente ay mas maayos na posisyon kaysa sa mga hindi pa nag-implement ng katulad na mga pagsasalba. Ang mas malawak na pattern ay pamilyar: ang mga pag-upgrade ng protokolo ay maaaring magpalabas ng edge cases na kailangang serbisyuhin ng mga application-layer systems. Dahil tumanggi ang mga core developer sa isang huling pagbabago sa spesipikasyon, ang industriya ay dapat gamitin ang pre-deposit validation bilang isang patuloy na kinakailangan kaysa sa isang opsyonal na pagpapabuti. Ang mga koponan na nangangasiwa na sa deposit roots at makapag-pause nang mabilis ay magkakaroon ng mas mababang operasyonal na panganib sa panahon ng transisyon.

Ang mga Node Operator at Delegated Staker ay nakakaranas ng concentrated exposure sa panahon ng window

Kailangan ng pag-atake ang isang masasamang o napapalayasang node operator na makakapagsumite ng isang deposit transaction na makakarating bago ang legal na isa. Ang karaniwang stakers na nagde-deposit lamang sa isang liquid staking protocol ay hindi sila mismo makakapag-execute ng front-run; ang panganib ay nasa operator na nag-sign o nagsumite ng on-chain deposit. Ang mga umiiral na activated na validator at nai-confirm na deposit ay nananatiling labas ng attack surface. Ang tanging mga public key na may pending o bagong sumite na deposit sa panahon ng transition epoch ang eksposed.

Dapat kumpirmahin ng mga delegated staker na ang kanilang napiling protocol ay naglabas ng gabay tungkol sa pag-handle ng deposito sa paligid ng Glamsterdam activation. Dapat suriin ng mga operator ang pagkakasunod-sunod ng pag-submit, rate-limit o sequence ng deposito nang mabuti, at patunayan na walang deposito na may prefix na 0xB0 ang makakakuha ng key na destinado para sa isang standard validator. Dahil maikli ang panahon, maaaring pabawasan nang pansamantalang ang throughput ng bagong deposito o pataasin ang antas ng pagmamanman upang isara ang karamihan sa praktikal na mga daanan ng pag-atake nang hindi magdulot ng matagal na pagkakaantala sa mga operasyon ng staking.

Binibigyan ng Hoodi ang Unang Live na Kaligiran para sa Pagsubok ng Deposit Pipeline

Ang October 26 Hoodi activation ay ang pinakamabilis na publikong pagkakataon para sa mga staking team na makita ang shared-queue behavior sa ilalim ng realistiko mga kondisyon. Maaaring sumumite ng mga test deposit ang mga protokolo gamit ang parehong karaniwan at 0xB0 credentials, sukatin ang ordering outcomes, at patunayan na ang kanilang pre-deposit filters ay tumatanggi o nag-aayos ng hindi hinahangad na path. Ang mga client team ay nagsal sal na ng Hoodi-compatible na bersyon; ang mga operator ay dapat siguraduhing updated ang parehong execution at consensus clients, at ang anumang external builder tooling ay napag-aralan para sa mga bagong interface.

Ang matagumpay na pagsubok sa Hoodi ay magbibigay ng mas mataas na tiwala sa industriya bago buksan ang mainnet window. Ang mga pagkabigo o hindi inaasahang edge cases na natuklasan sa testnet ay maapa pa ring lutasin gamit ang application-layer changes o maikling paghinto nang hindi kailangan ng protocol redesign. Ang maikling kalendaryo sa pagitan ng pampublikong babala at pag-activate ng Hoodi ay nagiging mahalaga ang koordinadong pagsubok.

Ang pagkakaroon ng responsibilidad para sa pagpapalakas ay ngayon nasa bawat staking protocol

Sa pamamagitan ng pagsasara ng isyu sa consensus-specs bilang hindi iskedyul, ang mga core developer ay nag-signa na ang pansamantalang panganib ay pinakamabuting handled sa application layer. Kaya, ang mga provider ng liquid staking, mga platform ng solo-operator, at anumang serbisyo na nagpapadala ng mga deposito para sa mga user ay dapat mag-implement ng kanilang sariling mga pagsusuri. Ang mga provider na mayroon nang mga guardian committee o deposit-root attestation processes ay maaaring palawigin ang mga proseso na ito upang sakop ang 0xB0 prefix. Ang mga provider na walang ganitong imprastruktura ay may mas maliit na deadline upang dagdagan ang katumbas na mga kontrol.

Ang distributed model ay may mga kahusayan at kahinaan. Ito ay nagpapahintulot sa mabilis, tiniyak na mga tugon nang walang paghihintay sa pagbabago ng network-wide na hard-fork. Ito rin ay nangangahulugan na ang seguridad ng anumang deposito ng staker ay nakadepende sa partikular na mga pamamaraan ng protokolo na pinili nila. Ang transparensya tungkol sa mga proseso ng pag-handle ng deposito sa paligid ng activation epoch ay makakatulong sa mga user na suriin ang natitirang panganib.

Mga Layunin sa Pag-scall at Panahon-lamang na mga Edge Case ay Patuloy na Nagkakasunod sa Mga Pagpapabuti ng Ethereum

Advances ng Glamsterdam ang Ethereum’s L1 scaling roadmap sa pamamagitan ng pagpapataas ng practical gas limit patungo sa 200 milyon, pagpapahintulot sa parallel transaction processing sa pamamagitan ng block-level access lists, at pag-alis ng external relays mula sa critical path ng block production. Ang mga natatanging ito ay nangangailangan ng mga bagong on-chain primitives para sa mga builder, na sa kanyang pagkakataon ay naglilikha ng temporary deposit-queue overlap. Ang pattern ay karaniwan sa mga malalaking upgrade: ang mga pangmatagalang architectural improvements ay maaaring magdulot ng maikling panahon na edge cases na kailangang pamahalaan ng application teams.

Ang kakayahan ng industriya na masipsip ang mga edge cases nang walang pagkawala ng pera ng user ay magdudulot ng impluwensya sa tiwala sa susunod na mga upgrade. Ang pre-deposit validation, pansamantalang pagpause sa deposito, at malinaw na komunikasyon mula sa operator ay ang mga praktikal na kasangkapan na magagamit sa kasalukuyang kaso. Dahil ang panganib ay limitado sa isang kilalang maikling panahon, ang gastos sa paghahanda ay may hangganan, at ang benepisyo ay ang pagpapanatili ng mga deposito ng user sa panahon ng transisyon.

Ang mga naghihintay na pag-deposit ay nangangailangan ng mas malakas na pagmamasid hanggang sa matapos ang transisyon

Anumang public key na may hindi pa nalulutas na deposito sa oras na aktibohin ang mga alituntunin ng Glamsterdam ay nasa loob ng potensyal na attack window. Maaaring mapabawasan ng mga protokolo ito sa pamamagitan ng pagbawas o pagpapabilis ng kanilang deposit queue bago ang epoch, pagtanggi sa 0xB0 credentials para sa validator intents, o pagpapahinga ng mga bagong pagsubmit para sa maikling panahon sa paligid ng aktibasyon. Ang patuloy na pagmamasid sa mga pagbabago sa deposit-root at katayuan ng paghahangad ng public-key sa panahon ng kritikal na oras ay magpapahintulot sa mabilis na tugon kung lumabas ang anormal na aktibidad.

Kapag natapos na ang fork at lumipat na ang mga deposito ng builder sa kanilang hiwalay na contract path, sarado na ang shared-queue vector. Kaya may malinaw na huling petsa ang pagmamonitor. Ang mga koponan na itinuturing ang transisyon bilang isang panahon ng mataas na pagmamalasakit sa operasyon kaysa isang karaniwang upgrade ay magiging pinakamainam na posisyon upang protektahan ang pera ng staker.

🔥 Labas sa mga Balita: Ano ang Kahulugan ng KuCoin 5.0 para sa Iyo

Mabilis ang paggalaw ng balita sa merkado — ngunit mahalaga rin kung saan mo ito ginagamit. Sa buwan ng Oktubre, ilalunsad ng KuCoin ang KuCoin 5.0, na nagpapalit sa KuCoin sa isang bagong-binuo na platform. Narito ang mga bagay na talagang nagbabago para sa iyo:

Isang account para sa lahat. Ang mga lumang platform ay naghihiwalay ang pera mo sa magkakahiwalay na "spot," "margin," at "futures" account at inaasahan na maintindihan mo kung bakit. Ang unified account ng KuCoin 5.0 ay tinatanggal iyon — mag-deposit ng isang beses, at lahat ay nandun na (kayang gamitin lamang ngayon ng mga VIP).
Mga stocks, index, at komodidad. Ang KuCoin 5.0 ay lumalawak sa labas ng crypto patungo sa mga global na merkado. Kapag nagpapahinga ang crypto at umuunlad ang equities (o kaya naman ang kabaligtaran), ikokonvert mo ito sa minuto kaysa magbukas ng brokerage account at maghintay ng ilang araw para sa fiat rails.
Mga aktibong sa totoong mundo (RWA). Tokenized na eksposur sa tradisyonal na aktibo tulad ng mga komodidad, direkta sa iyong crypto account. Isa sa mga pinakamabilis na umuunlad na sektor sa pandaigdigang finansya ay hindi na eksklusibo para sa mga institusyon — ikaw ay makakapag-access dito mula sa parehong balanse na ginagamit mo para mag-trade.
Kita habang natututo. Hindi pa handa mag-trade? KCUSD ay nagpapakita ng araw-araw na interes na auto-compound para sa iyong stablecoin. Ang pinakamaliit na stress na paraan upang gawing produktibo ang iyong idle deposit na may 4% yield.
Isang AI assistant na nasa simpleng wika. Magtanong, makakuha ng konteksto ng merkado, maintindihan ang iyong pinag-uusapan — nakabuilt sa platform, walang kailangang jargon.
Isang app na hindi nagdudulot ng pagkakalito. Mas mabilis, mas malinis, at mas magkakasundo — intuitibo agad mula sa unang pag-tap, hindi pagkatapos ng tutorial.
Safety na maaari mong i-check, hindi lang i-trust. Isang EU entity na may lisensya sa MiCAR, Proof of Reserves na maaari mong i-verify mismo, at internasyonal na sertipikadong seguridad (SOC 2 Type II, ISO 27001:2022).

Lumikha ng iyong account sa ilang minuto — at magsimula sa platform na gawa para sa kinabukasan ng crypto, hindi sa nakaraan nito.

Mga Karaniwang Tanong

Ano ang eksaktong Glamsterdam upgrade, at bakit ito mahalaga para sa staking?

Ang Glamsterdam ay ang pinagsamang pangalan para sa mga pagbabago sa execution-layer ng Amsterdam at consensus-layer ng Gloas. Ang pangunahing layunin nito ay ang pagsasalig sa proposer-builder separation at block-level access lists na sumusuporta sa mas mataas na gas limits at mas epektibong block processing. Para sa staking, ang pagkakaroon ng on-chain builder registration at ang kaugnay na deposit pathway ay naglilikha ng pansamantalang pagbabahagi ng queue na nagiging batayan ng front-running risk.

Gaano kalabis ang deposit-hijack window?

Ang window ay umiiral lamang habang ang mga deposito ng builder ay naglalakbay pa sa queue ng deposito ng validator. Ang kondisyong ito ay tumutugon sa panahon ng hard-fork transition mismo. Pagkatapos matapos ang upgrade, proseso ang mga deposito ng builder sa hiwalay na contract, na isasara ang path ng shared-queue. Kaya ang praktikal na tagal ay sinusukat sa mga oras na paligid ng activation epoch kaysa sa mga araw o linggo.

Nakakaapekto ba ang panganib sa mga naka-activate na validator o ang umiiral na staked na ETH?

Hindi. Ang pag-atake ay tumutok sa mga bagong deposito o mga deposito na nasa queue para sa mga public key na hindi pa nag-produce ng aktibong validator. Ang mga umiiral na validator at kanilang balanse ay nananatili sa kanilang itinakdang withdrawal credentials at nasa labas ng nailalarawan na attack surface.

Ano ang maaaring gawin ng karaniwang staker upang protektahan ang kanilang sarili?

Ang mga staker na nag-deposit sa pamamagitan ng isang liquid staking protocol ay dapat i-confirm na ang protocol ay nag-publish ng espesipikong gabay sa pag-handle ng deposito sa paligid ng Glamsterdam activation. Ang pagpili ng isang provider na nagsasagawa na ng multi-party deposit security o guardian-style oversight ay nagbabawas sa residual risk. Ang mga staker na nagpapatakbo ng kanilang sariling validators ay dapat siguraduhin na ang kanilang deposit submission logic ay hindi nagpapahintulot sa isang kumpetitibong 0xB0 deposito na manghingi ng parehong public key.

Bakit tinanggap ng mga core developer ang isang pag-aayos sa antas ng protocol?

Isinara ang panukala para sa mga pagsusuri bago ang pag-deposit dahil hindi isinaplanong malaki dahil sa presyur sa oras. Ang Sepolia ay naka-activate na sa ilalim ng umiiral na mga patakaran, at ang mga paglabas ng Hoodi client ay patuloy na umaangat. Ang isang huling pagbabago sa pag-uugali ay magdudulot ng karagdagang pag-redeploy at pagkakalat sa testnet. Tinukoy ng mga developer na sapat ang mga pagpapalit sa application layer dahil sa limitadong tagal ng eksposur.

Disclaimer: Ang nilalaman na ito ay para sa mga layuning impormasyonal lamang at hindi nagtataglay ng abiso sa pag-invest. Ang pag-invest sa cryptocurrency ay may panganib. Mangyaring gawin ang inyong sariling pag-aaral (DYOR).

Disclaimer: AI technology ang ginamit sa pag-translate ng page na ito para sa convenience mo. Para sa pinaka-accurate na impormasyon, mag-refer sa original na English version.