From a6ac1ab35f839c81358568d0b82753cfd128d39b Mon Sep 17 00:00:00 2001 From: krofax Date: Mon, 14 Oct 2024 11:05:27 +0100 Subject: [PATCH 01/53] Initial commit --- pages/stack/protocol/rollup/finality.mdx | 89 +++++++++++++++++++ public/img/op-stack/protocol/tx-finality.png | Bin 0 -> 48407 bytes words.txt | 1 + 3 files changed, 90 insertions(+) create mode 100644 pages/stack/protocol/rollup/finality.mdx create mode 100644 public/img/op-stack/protocol/tx-finality.png diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx new file mode 100644 index 000000000..e8775afed --- /dev/null +++ b/pages/stack/protocol/rollup/finality.mdx @@ -0,0 +1,89 @@ +--- +title: Transaction Finality +lang: en-US +description: Learn the concept of finality in blockchain systems and the steps involved in achieving transaction settlement. +--- + +import { Callout } from 'nextra/components' + +## Key Concepts + +* Transaction finality: The point at which a transaction is considered irreversible. +* Challenge period: A period during which withdrawals from L2 to L1 can be contested. +* Reorg: A situation where part of the blockchain is replaced, discarding previously confirmed blocks. + +# Transaction Finality + +Transaction finality refers to the point at which a transaction is considered irreversible and is permanently recorded on the blockchain. + +## Finality on Ethereum + +Ethereum is designed to provide strong transaction finality guarantees. Here's how it works: + +* Time Frame: Under typical network conditions, transactions on Ethereum achieves finality in about 15 minutes. +* Consensus Cycles: This finality period is reached after 2 [epochs](https://info.etherscan.com/epoch-in-ethereum/) +* Block Confirmations: During this time, multiple blocks are added to the chain, each providing additional confirmation of the transactions in previous blocks. + +This timeframe ensures enough block confirmations to safeguard against reorgs and guarantees secure settlement of transactions. + +## OP Stack Finality + +OP Stack derive security from Ethereum. Finality occurs when transaction data is posted to Ethereum's data availability (DA) layer, i.e., **Layer 1 (L1)**. +At this point, the state of the rollup becomes finalized, similar to L1 transaction finality, preventing reorgs at the L2 level. + +In OP Stack, transaction finality involves three main stages: + +* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data hasn't been posted to L1 yet. It's circulated to the L2 network for speed. + +* Safe: The sequencer's batcher posts transaction data to L1. Any L2 node can now derive this transaction. + +* Finalized: Same as safe, but enough L1 blocks (>65) have passed to ensure the L1 data won't be reorged. This prevents L1 reorgs from affecting the rollup's state and transaction history. + + + The OP Stack ensures that even if an L2 sequencer produces invalid transactions, the network nodes will reject them, maintaining consensus and security. + + +## The Settlement Layer + +This mechanism allows Ethereum to establish a view of the state on an OP Stack chain: + +* Rollup nodes post data to and monitor Ethereum. +* Ethereum processes transactions based on its consensus rules, without knowledge of the L2. +* For L2 to L1 messages (usually withdrawals), the L2 must prove its state's validity. + +To ensure the finality of an OP Stack chain's state, wait for transaction finalization on L1. + +## Sequencer Reliability + +Sequencers are centralized, raising concerns about potential equivocation (lying about block state). However: + +* Sequencers and all L2 nodes must follow consensus rules. +* Invalid transactions are rejected by all network nodes. +* This process is similar to how Ethereum and Bitcoin handle transactions. + +The L2 state is considered final once a batch is posted to L1 and enough blocks have passed to prevent reorgs. + +## Challenge Period + +OP Stack rollups use a 7-day withdrawal challenge period for a specific reason: + +* L1 has no inherent knowledge of L2. +* For L2 to L1 withdrawals, L1 needs to verify the withdrawal's validity. +* The 7-day period allows time to dispute withdrawal claims. +* The challenge process uses L2 transaction history to verify claim validity. + +A successful challenge (a failed withdrawal claim): + +* Doesn't impact the L2 state. +* Doesn't cause an L2 reorg. +* Only determines the validity of the specific withdrawal claim. + + + It's important to understand transaction finality and the challenge period as distinct concepts: + + * The 7-day challenge period verifies the validity of L2 transactions during withdrawals to L1. It does not apply to general L2 transaction finality. + * Users can dispute a withdrawal claim by submitting a fraud proof. This ensures invalid withdrawals are identified before the state is finalized on L1. + * A successful challenge impacts only the withdrawal claim and does not delay L2 transaction finality. + * L2 transaction finality is achieved within minutes after data is posted on L1 and confirmed by approximately 65 blocks (\~10 minutes). + * Even if a challenge is successful, it does not cause a reorg or affect transaction finality on the L2. + diff --git a/public/img/op-stack/protocol/tx-finality.png b/public/img/op-stack/protocol/tx-finality.png new file mode 100644 index 0000000000000000000000000000000000000000..c1d40fb48a32445b4950f2bb8796ae0e6e3da006 GIT binary patch literal 48407 zcmZsi1x#EG*rkEuQi{8~ySsbQ7AWpeytoch+}+)ayA&zzPLZ~_yZa2Y_si~|>?WI= z00}SyS6(^iIZ+xP6);eVQDIfKRY)S_;xIbu*;L zFff!bO0rTq-o|G}2>#2T2m2?RW%V3O(+*ISdRA4w{)>5%7lx+KtTqhC~N` zg=Y3MMnmtkB*!u7BvQc|H-leL8J~;xB9bYVzhM?WDO_VdkB(#}*+L$)yqHlL|Gx*V z9O~-#h_DFzfv|80qP!StQlHKv$&Co(3(@shB?L!`bXX!9bobhm_TL+r%F2$b(@CVg zmEY->^^r{Z=^Wbpn^8ZdiDJgDHJ@kB81x-Y+@bjIS8$BfF>d(w z$z}7}ncCaiuan|Jncvi?!POSD*{hxO0&QKJM>D#2JXC~BZ8k$XDelBdz5{vZGS zL&|}KEniZ>yas{cVPV7kFf>PAuMcc@rz;dVqM}zyh3k2Xsn} zI>I70S28B7#D~*@oX@(RN%R={>6*+8r@z~3nKwVn2Ky|}lp2|umX_B)*N8`HB* zxR!lDrNTG`9Vj^!>~nbgK8N3FU?Pp>>g2cm-ed-5&+FZYu1O%>>C^p+Nu$RpzvWCa z%JE{E!Vev$>w`FfI+MQmZ~GHPMn64WTwFM(xXjEtzTGqX`}=FOIS{R`t)2Ef{I1s3 z>vCth*_(;OXEPw?6d&wIrp9P12z)`Q{#+}aFY041c6oUVDlz)&c{E>wXDcmB9M z4kC_9VNf5rKZTlJ@6fq;c<@!(9ryj}dQ=coS+Ad|Up>sY=ZpI6WZ{uh9Q6Mjk_*L> zrjjrtv1Bn_9;e0T!_o2>g5???a|N+pA1@V_YxL(&bBrtXOXwHM)EP9Ti9O#Ty&vkA ziAY=+M;X$P^%f-bvGg=3n@DSL>6h;4=pdv`Zf_UpdOU*7SgPW3eiH>wvz+lHtx)go zR2Gk3i*1rD4~c+NY?XG!#Or?!BrXgtLXcB9;aD)K_c4<@*rcC^f!AvbJ{n;rLO<-jwS@Zasf z{J$Sc>=dwRX{}RFm-o{a)t@%|7$>8jC_yn7-j5e#BXMLg=Mvx`juZc2Gnoh_T&@@I zmpdk5_an;V^v%H6S}^2bn#9|$Pwo$IU8P1N94bDmCGY;-e2IeXdKVutuS1Y{&+EX3 z_{7s~*M1mNO2yU~he9H=6*D|Me4%DZc&4yNwiFGQpdj))MD!ux>NI@YSMKQO8acsx z`#Zlm*Q%oH4~0Bd>elCLF7ro#vc8BoZ-}1#ZO1%au9Zt?)h|Ie`dw{!|F!+$iZlAz zenZ9z`a?YG087QFjIr?lItXI6iS66awjluiua;; z@FTqV*K4ul_awso%gFO*&QXHmiaA;hihbN+{~`}R6m1{JBws?@Bee?2Pke0#gY?T|eX z3L)I+^@~B>XW2SX?Eq23+Y@cgvmqg5`KmXT`cIYKyWw9-s*xlN`sH%KkrwDNSqAX!z zVgiqZK&AGl1&h(NyuGU!PD0jlvb&4UM}aLFLzs$Jm~Ei$?4SoFfc{+=}g2oStqbIg)^T{d;)WcDqSnKhROO zJzn`8938gy_P*KJUMRd{4vc)NKLi1xSh=mV=DEqt|Z z?LYzOEs9CIg1XrWcsM|+a5j~$>0pv_k~*8t-PylLKP-^E;f6LQ&t@qN4q9Z#VzvTH7H zXl>+E5B&blY}>4OPVPJW-2|Hb^X7-aYDo1%z1+DZn`oao!r_jKghyKZxkw}qJ@AyR zw)(Zp;w6B=%}bER-*RQjX;&}z_EOwxr|F-yWZd?~V9P@<{?0clvjh61w>lq`qLH zEi4=rDCz#$&(AMP{^9(u?nZMU1TmIW2o40kj*$KM)9XCE`EW-0#O@Y<8jF-P#7M+* z=ilbxT%$IF|6+9pVc_~t4+5W?X@SkiU`3d`&$VC1{nJ^EsQKdMV(5}DlSl`bJ?&9lV|s=HT^nt9NU8?^G#pbkXO3#qM9qD4)^fZAAT z+TCnIT2^w)JMLbe!KW7@xwFLz%y@D!X6Y7N&2pS0*>PM5+Xjd=mV(C@o!zht zW;U%_b}Jio==3$e-ndUX;(;u2fC{0_VZ*!udBZl9C*v9~5SxVm1gC@>*n8GII308tFZmaO}(diCK3 z(EpUXY;F(OEDah1ljf!6Pct=fwkU$~dwh4^Ag|bQQ%O7#8;trI8pyr@i`p>mZH|A- zH#1{B8RBN0*1MG0%o51gF>WLlZS8^@F%Yl}S#;}SE7S|ju9M{y&vU=bDS)2$kwr!6 zw;m9?Y(V&d~Rf2 zm-{jI%l&B#aHdL(Aure5%^4gf13e!0hJCJNB3>8LQP^}l`<<7kRR0LR=U6KvV7`0H z35CRE=3`~_%m3t0jwgD=A|#BYk_q2B`CYBoY^_!**?u=Js+cX{%pT|Ib+HS6wsKJYE!A6UI`P>F-P-z{J1>N^r9Sw zkR-zpv_EGsqtbps{Sch`-hr53RK@=H52p8-U<9;*ndQ&aL6aG5qjP352$0l6f%_1( z9DcLCO3lozZ7M9@koq}A%O%xnhO0IAJq;x4F2<6SmysU7M|h%EjUs8i2Gd}{KxAJW ze0*jQ&kMd$JoxSPQcFQGLj7}_yUi>P7260#5JJ|EDua~#x zM>kpi>VMlD6IpbfrV1n|n6%3+KcQ{(+>cbwm$SX4wuMa7k){NDPBpFeqq$9Ag_ z6VWxw4t>hVd83K$bNjUdsRyJMVOQ6E&B+5BOk8Ok18z~>_t$JMeebd+QDZc{M3rRLn-HIpkYNbTBj zlGS~hOn-X4?BnvCB5ZM79AOn2;QNqiK9*Q?MJVw;jae6elrfmK$!eNiAO0&Ns(&Od zr74Cs4H+5PzJJ9oov#sT@F(w?UcW<{a3YLMV175h-jOq(Vl!wX?fkZ%>^^};FjE4I zGK?lgaG7bX*3(}c{POK8KCWmqFkilhpa{0J~ zyN(+ed~0@hDIxh4N}uu^X_dV4s#KYsVr>-YM;&6EGB=D}tx zn@!~3KVF0$_oBVAG&GOiCu#I|DXn<)2icXEm`K1_TnhVjHeYP`-Hg8nDsmkJ1br>w z?Buhi>_!Th+v6D9_Q7)Z^Jn3FLhb{9ME)R4^P3WbzAw^mzSHD`4CgNHYWHCnAD1 z2LDGXX&`v|6K%0-FoFK7%{Dc#w^2oCJe;jH*v^~dvV5K@W;m)V7-7R?yV$gv%s4*3 z#DyTd94Yj!c3GjxClIlTl3k zPF-;TCfdbvwTOa(`cfmUQBzN;`x8FS4GYpHn^`jr(2l;i+W~rw(a(=}31c4eW6AEv zi%Lw9Z34Ufp-6NwwnJlBwi`8_QX~7_ky;a762j>%O;tdb2^mnH%cGH?kV?oG8``o= zha)pfp;v=%p2#fwrD%P;P)7SV@+LfoTIUSsiGT#_1bA8(T#Wiw)GKfFAPPaG3uICV>tjqi(pnNPsw+P zrskY@5K0%5v31l~l1#nOU?vkY_RAR?vK|Z1nMTJd zN*Y7JF3T(?mdHC1&~Zi;06cX)(c1Lt=|^xy?H(Mz1L}(oRWk*#SafR=g;DTdbJ7rP zun?Apqv250VVNCc@Yx3PM7-u|^m%aEzM#*{RMBRS*_t)(40E~;$cBPFt{3D4E55}i z`6_qHRM2U6tCf9DQW!r?ZPcM(Uthm|8nw!0+-uz0&eT6AXGdSN^SYJu({k?DypIm5S0Ak5{l(@xq)MY9=xTT!S2{JlKANM zKDM%P8lgarXwZSQt{wmsdu{_3^@Je4`{-c};eU;v^KEdhVz+KaWo3^HQA=T4*2S^OyL_ zBE}D!xD6xy11Y43Ud0;gm zsVof>@qK5hDkVANqkLh-S`wdLQoG!`IwG~qlt}|j0)-fM_}70OjeEu^n&YKY1c$+@ zWhSTlWsi>$WD*I2UrMjfjE384DzXcTZ<->@8(THCXu2)>bUCNNOw6HK=kJ3~&Z~zmOhBMp z`th6>$&ET`rBB9V%T4Fwj?^W96 zzm_*PTx7K{A?^ZERgvkvmlP19?#46yl&!~HF+cuvcB8Kip2;D( z9{vjoPZ%ZUeoo$Y>gH12Mtv!kXPU)Lu^8gs8hyACUoK_mMG z<#?$cL_!Bg9OGecOOCdxFVC+uVWIDGwacW#?~Z8}Ht*}T{u6X}nxJfOb@NR=?M_Df z8l_a3AJsRRn2~AZ}@nG8Tp!_Qm6|=x&urQ$z`r>(1uGiHLsNV+0-?lGBy?lx}C@7GCpXuHx$^r*+|_ zDs6?goH&K*PqpE8n`$^=xzoxFYT2xaNHWhAAM=vwD}XH*-&q~#fLHShVOATYeUOKo z(sb;AYL$war^6SCt4GXVb7q4YJzqX)a=Rm}w}R@-u735yZAjwQpdHTcZWV=I-5JtV zq4E0K(w_b6eD^W_ql;=5wkJP-2XqToR8(}X&PW8Zz!z+>%^Q*_FF&Xen-%%k?45U~ z-|L?xi+&fE#`4+xE##Sy+a37}uQOGgsetpJSdY_{@yBdF`!-qEdko{#^K-VOy{$x3 zRj5-}=`+9M0xk}{_tsQa-_^dZ2}-wE39N&)h}(<1!)BvQ^x&~ZVNsjuwzQHRm7x5F zzYmwy4X$CAI|`tZ{tAM9H{Y9Nw90;{<{*IGBR{0YK?;El`};^7@wmWV{#Iad@44bop@jiNHQkS*D>cFTFi zt;_lhO*MvhgvQC)P^1hrg^drqn?F8rI!y`ooMIxQ57k`Sm_J9SRciJK_de~QN!^u{ zL>?mgHD067XH2T-D>uYiC?phr{rz>|l9yARRDvqLwrnzeU}OYez{zkla(i%i{@Eim ze87){-{C`j@8QXB7uSz*a}64u?Mf;1$#nfojYpwb{Ha)}>%5ZB{u4;nD}drbVD!_2 zCts@Q0gBWPwQ!)khx~rjJ*<#pPS`21#Z{DiE&@CgZ?~cPtcYn&QEknvHypm=iwd|I zX=7@=`JWS&SeOfDgW7t7<8{&Aj+;=(yHvzBDU zdUF%x&4N!R>l+ppaTwIe2}0A|&4PI}A5Z)>k=Fg(6>JqF33DoDbJItfb*!l)#^cO3 z9-F_ot=xKFz{=a(G2*j~d?st8+ibMxD}e^RA)}!TA2nJuKu0ND!A}LYbA@KK-QD!j z__qkL9bB!qdr>J*fysgNlKf>>(SIVbX!deA2NY=XfARja5pvs?o+d6B zSlPt<>3JdfLuaPRx;%d#cCOuvf{V1`V-CGvu-ttte+qxB)`wunnKL2Ao9od^ovPxq zoPzhHK{3@V@88@tw0@|4ZloKyte@RIcCl1kRvLf8}zuFS#cl`IgX@6pTNss*3!C&{cIsI{-t>>6SxP|MdYnqOq z?MbZg55`uACXS*iIkVJT)lvOUiCfmKCfh}2VLw3Kskja;;|l>%;2CsPx-}g zrl4CW37ZRj6&3cl_zw6M%CJq#iYRC+ODfojTU>Bx$?`M=-Fjr_$Nb07Hi{dL~Dp9t)QgjzIzGnTX`aO`d8& z*S-f@4!<)tLioHgaartAI*ZBY!qQyTa^q}Ja;x?lNUt0KKn=Z zXYqcie(X*%K~qY=O{!Mf=H>(iS`eGFZW$kUViWOLrYf@A4P8!2y9*;{hS$_aIm{Je zEmWvSAfVw>8!WSG=?>XaFHYr)`$h9#TmYI?S1FlxRSA~5qTR9(U{a$0r+)*kLE~;j zUI_6BF|#})vU>`T!pAD4Ie9#9jz`Sx`{NHq-s}dwqQ-r`bV@67sLE@1tbt zEdJ!Sc_3;>3)$M*YZtPW^%+7b0zvnIav--y3eBdU?ibV_r5!!Pdm%DgnVKc?yI0$x za2LO_r6-P-*x6qeFKDtioB?eus4$()h#9PEGh3-yGNfmTF`L`zrqQOV&vkKBn8WYL zY~1HVGb0A4`~kUG`*4O(+&^>ab91BTdi_bUb6+p8N~2}s4ZKxOX|00g!wn?(~49($xWZ?4{@T#LrC%l=dv zj!@HKWF-oU;3C!8|F8g~A`~WPYdr?k@=J;Og9^i;V`-nNKT83cAD!^%oo4wvuJwcw zs}29>p%1%1oi}^gl4RfNR5I$Y!-}b}J`lqAiTFt!ovk*$6K8*EEHrD>#edxv^L_e& z$E-7Scg$nz>>L4z0Yw(0A6;BM`gi1F_B(YLZ527E(~`yjQL)75)_Nh8&wiP8L0bWB zdTMMLFpuCjGWl|2eHSW=q*O}6k{IP%rbtjY*u=zicU~`T%*K<4wG1lNzi=(In?Zb| znl!OkG#UyCZEA30QI@gY-gazP+tkp1eX17K>~O(qahQkGtuvPU>3L2!U}J&9ZfhI+ z(&QA$JDb8#-;z$b1%Iq+kz#AkVbYtNz1UQ-bMr@ozYhYIEn0#0p(n+H95tsP5P2X8d%GS9nS44~Qk?H9VzKQ-K-N zIea*_j?3Cy9@&22^PgVGsOXZX%NJO`_-e*A7G}D8>RJ#=Hu$R}p91$sQ%2S2%Is~b zCO4XG>Un45#ieCru0{($=4%U9=I&UP(Ko43c7t;Ce}CJOxDf(uBHFAF;-qg_$hbs2 z&pvRX3n%G8C+}R#D{)W@vZz(9dVKFuoi=+}IB);xxGd{7JLQjj?eX=H>*aK_-0jnp zC(h5W{!9hi6H;Q3SzhkefWV#);tCbtIrL-taY!|*5^1|>24Q&^uZ zo?=CdeyXrHac$K>`?aR9U&uUiN%ND$Mq^=335u3>s4wH`~iMerIJf&Z*F{T-D>3f5?-cR5~ z`C=7kYVy^EM$cC8eFb)I3%wTaMwq<@!ZkL>FX&{#@PJN+Jy-#V`I?lN%PRGco($S{ zc9A?kCfg{wLhX8a2UaISJ&F*}aB)MU@5_0Q6h$l)>m|rU8TrKBkw1{tDwWVn%g8^p zTrE!$>}b5q0Ogelw6%02*o9pG4q`W12Ta!}wGe zfu$u+X?L|~3sl(PGnVq=x97tGI0G@4UohaCzs_(tA72{6l`-Uk_mqP(>WzzR9?7-X ze=Q4k-TxJ((3_B?T>#8`WXuJn4yScrDM@fw|H{!ydx2CC+61vMfxe0&IjeE8AmV#c z+WWrLeFwY#DV&L;%ibLJ9#Z{m04rf}J!;S;(o|E3C1h_MQI$CKpMm5w&ERTV!_S$G zsbarhwgALqxkO|p`=ci_OdjE!NKeJVRF8%Kv{go2)1mw|6IUrdsD>?GhDY*k7-8_I{YU3k(+XKlR&@L~N7ojl&|7uQu{b{Y z3WZF?0#&3^h7~?F;wV*Y#vo&}x7@1ig48Ej7~9eaQ*S{hUmuhOI=^p9d6|8EOTmqZ zbAa%_fa7zt_={1uH&+%yXhoel@C?!p+jxFKc0ozv$ci3H)gi8MKvu&Pu&2p-80VFi zSITM|yJHY{9>tU}-8-7+Rv?DsrPg~LJJjq4He%dvr+>0vGnT%IVIWC&t7mg7#fGO% z>TW&ciNMV)RBF;FrBOrPQ;4&|=@wjDU4#b!1y=rr{$plP6yQY~_xK7Y1#4*jISR1B z(Oag{Tob;T#G1$sqV+?8m-?xMe#NZY`22mf)AC|EypsY7N#mC@!7Qq$wb^! zkEqgmcZl+cnzUgKsdESTply7EJ(3Y)1O+3EIXSY=$tMJ40? zN35}FQ31wX6h}-FgESITn`}a&& z;|yh`2h-!@SbmRhjNzvFqMfnjhu2r-E18-K#fi%G`KWlb*>Z@@)=mp@32ekAWy*~T zvspY9Rs!ja#?t5umEv)U){XGW-cMJ--W^%|z@8~|&29h3^1IBfMh>CzHzxcv&rny* zMOJVJzVVE^x%`4&MhQ#J6WQ9{JpevgERAU}r!$bI?;&5#v=a;|DCI*d{LvgWiMH zfy>K4JJpY;la+avJCJRDWSNfsk^1>0iH*aTdm_PX%-6Rg8}c9HuYM9VUA)Ld5FUrK z-o8hMy%!>}MB;y2rhFI~O(KZX#6Ljv%1 z;+0Yu%=*F4l{!(9o?T8ZZo6b(p~Qds`rclumy~U$v+)et9pnyJU#O#^1EZn45zza# zUz}Bm{|A(4epld2S6N(8T#yy))(X1okidg70)&u-ERpV^mnx#>iwe5$kX#_Spo^qN z0E*67wqMU+ETn>|nX4gUx>yqxBZZl1&m_|u^?xS($cbhJ`m--2#&N@#zl zV2;wD&eso#_BW)J??l8J-0Z!VZ*y2HQ|EK6g@M9!2i_9f85$u}PTWN%gWyY>NpGdx zB!a6i{&mKwWU!+ZQeg}MRD%l0>YTDkLUSo9#jC6`8!$2=gLy0|Obm6_!c zel7y;-NX(i7hvZ;`h7|=l`m$H*h^$}d;5qZYieY11_%rbZ&8s0PIl`W-LfcL-mB!% zwbtME$La3lWOENqYoUANDXxG~C{;I`NJSF}HCj}8*&d7-%NP4enSzr$w^S%K5=k1T zSv-!DmG{eizMn9P%jI~7&Tf2nYb#P30gX~!*2Lv4-f;mi#-ac}KGIB~@aHx8u4bdO zoDZZ-g@DU`*}(@X_|(wQP@~u1M+&k6_b^W>?sG!>nbjcP@9`3iTUcAE`cpN2Cp>W? zue2SdTO7Q*CFZwc@Z;qQh3A83d3tqVJ)j$i3riSBgoEJA)d5dx0hkqGZrw8(glIBTsBbz;5^<^z!8%L~B0gsRwUi7Q>XEG7UYq zBmM9p67b-owuhv46MJF+6N4V{PZkfzY_)-EVWix=OnJ54x!_LzcbfnYuZ3`|d>k=d zPn2Ei%j;|ZG+Q3H#=15ez~Y9? z6}Y=)u6Kr~==5Vxix(4&=Y*PVN_37FDvf@&>CdXn+zCX$e1$BRhuT%<;2tYv0fxVk zW~t#S^;mA4`4;i{OI1Sv09GbvxB3r%^M6}AlrNZg5I8HC%&$tH03TuU%Y$Z^I5}b1 z+3OGwrLEF?bf4S#+?1j>Hw|C1n%S0KaEt^0(;wLkT7Ch3ybE|piOcEi+#yLk05R&x zm16U!AHjN;7lF(VzO034OtreiS@+n*ru z#@IJ$QV7%Kc}#s?V>{JZ<~A7g_AZeFaS?v?9>sdfG-n z@2#4+QR&YBYX<1FmKT7Po-Y2o-FbZ=GKpsU;v!y?MnT!c=|QpA>oQ+fRm9`u`_6F8 z;QY9fCBBd6+ReURhiUMgisNEA+sR5j2Vy<{m+>*m%aZPrx+E5xkLZNF$iNC@NggZO zq;OlK-%Q(@D%Mia=glsLT_6Su4@1M>iQ(ww97FvIWdOga$KRZW#?Wf%L-$uq%7mH_ zi-jJ%Z}w0gF4kxuP=H-T(p}-TT`1-Hx?ICFQcQeV0H?FG>ZNJI@v%1#11S5Qp|6h= zl)SuzSv)pLEm&@S>LgxX*Hg7d&4>@ay~ptso{BPCowo-?fb8#T%(GRhst5Z_5h_+ZXNntE@Q@Mr_77dN~tdpGW03|K(qdk`xSYm*;COGKhxjL>YDPq zew<&MEU(Q0@8xrF*3dF0 z0R{6^DY0so$CjonAiwQrm^4`56X!mkqJP^Pi>Fu1E_O|!A4?YELB6>?Z{LiLA9Vkh zm}trs4%8^RB;Ae8Vjr~U^^h>MM1IFFT*(pWWT=~7mvf!=1n4BfQ3C^N`{y~*RaP^ z?Y-^6+M-4*SMutMg(Ji}6Qse}vlG1Yydc23E>ZC@A2^eX*XQjr8g+)9dLp;iyQ9e= zQm|9K-*InhP;CFS5cNVlU092V&|+Cw(J_emWr3JNgY|SaG9BB&Cjd7|eP=PAOb2W% z-P@7jS$Alt=(2zk1q1@HRIdmr(hk2KKoDt|Pu`Hd%oY+QE<>ToDd0fx6BZ!@}$p{4q%!EjRQ3X8EgDbO0J$=V) zt>Jrk@@Pcc7TIChA%R?} z>twM)z0u?I--1BfowvDl+;2qZ(=IT-F-FjIlm|iN%{ISzWhuE zp>RNJ5@_k?^&T!q0}0gci^F2B?55Q%&V^7D%TzL=+bbRcH1qLbu0NFUaywYq<3#bu zL>}7+v=_2#_XaSjggn-)7wbJVj$S^_g-lOF2<+z%~_xXoWE8ZRdAWUa&o zlT_TD5O_uDk`cA7%R`2VWq`nWe)_z3fYP$`|&U^WN*1tuN^n z(tCj%<5^1izPKNA1&p|>8JYXJaoPY_k!Lv3EwB`rfj5Xd-v z+hEd4e?DFmdDR>Lw{ijK6Yd8zYS_;;dYUJ3)Fn>%{(Y~H7bQlop2=O~;!akR>AzX} z^v$<+Ph$f79+hQ7;)jZdqj#oH1+*yce(RdZE#VBSy=`{*yfgagE;sp^Z61K@7=4Jy zSuwu)7wP||^BKIGouqLU}IV(Asi^QJWQGWz!J6)G;&s0xZ_w7 ziTA*GF4cCnc6AWfE}DaA@*mClt*fh}Q0;FUwY@F8xbG8kTD6Y+?ZGsc`4BP+F6Vu# zc18Tooz+spX}8ZUz4dHXoC*QEd09n8X$>Hf5V7U7O9Jr`EC3|*odj@w&6|{D+vQ>+ z`8d)rVm@)a!?v899K!I~e9``x3=X=}$eZmyzpEMl6GQ*HXJe3vqpMR$;E9D$3aUo5 zdNaO#0^66rRsEN05~3IQywfYeON;AvFoShD-DshZ#BTJWXZ^g^d`Nrv)2l$7@pDZj zI6nyp*BH=v)ft-e5|T&xLCW#mCJ!mFv7?=PkLfhULb^HG22H=D61_&4aUVA|pQFJ6U`tEm`qV0FCAJy|YCp7u6F@8^NXVeX9)OR{pgVSBb?Z zrLL|H4bR4ExG<(oA8*|W?}-_QRWG{!ey|V44mrL)0M>-`w)kwlBw$c zbcKY=B5DZ=Qnohpd^;G6YCHc^Y?o5LU=y45&b(6zI~5SiCbKD{3}aj4fza!o@Mb-Nkge0nb;hH zh)%t=9}Siy)#o`75vCFg0G%0cFf2*NbwoB6fV#~#ayv6QUEvH3jU*K~$tZaTGRc(( zW9El}AVtX@LqVbb?SVOG<69z@NB;9CX5A>+8%y8A)bSLcuzlQ{%FdClOqms$E`JP zM&vN*PCPo8E0U4B+@9sJ9*bHdr_9ej(>ZN=1i&*UY=f%O+Su)B(o9^4D1CGH`L;g7~$7gIZm^#652$~%YW-zeKsCNyVY(dIV zjn_B7RqjsK(6YF#u%+;QdS<|7$9BA{D$IQ6A}s_7)2snW72bw@D9R*!fi+zj0>iFv zI#-e8N4d;+C;rc6`$9MK8|qYl%i~1EAuZ*&eWxV6H<2%&8ce08e-2PZ3}kYZaJe6G zUSAQB2srx!S+zEE)o7_I8wh~u4|LtzH#$!8UkehG2|sElS*z0)7k|}~qMW$@75wh{ zZd_XlYr9`s@$L4IL$RPjIgN#=rjPg8X!i-S^8)z|8F36PeS>&Q{_6}tLL*?qEh}?a z`(``eEfnn!Zj}ERF7x%<5g#zQZzA|4C~FSNV`x@evvFDpP{g>xE8zk@Yug z?09nfT*w{&wj?Q%pVxq&Z_pN~Fz7HM<6>lSg@6kYN5oUUyH}-cUdS~ViiK3`7Co^B zbcmrX+LplV7Q50JCcg(#y-stvvtDy7u*`5gQ~86ZXYm#m{$@|B$hW;ID!1R|e%$8$ ze<+u!HT!ArAQ>isOh>U_Is#=jb8Y@yZ4d7IThKW8l*7JRoj9H@J8CqT!g3kk6CK=; z4?~%mO|5k#FMDGTAv7;IS%QCZZ3P>7zsncl+XQw00-YLHizsx?i0^dS_R&(j0Re<3 zK)a^8S*DS>|dIe2!y^n6>yR~P|Ye;L(2Qo75b6mVR7+M z#Q5~`l4GoPDL@aTq=2Q8Dh|2R=7M7)$zuNrf(9lzt1_tp=sk=RBZs#m5b%o!`^)C) zrWQ>ZT6}RTi%tVtN+1`0)_}4_+Wf+ia2*V1^3<{bc!^agzpron_TwYm{hKUX-+ysP z@Qdr~AK(Vm^#?Go0S!y;SKNonTRAejxoja7{HNy^6d2?P2~ufzz1z(wcj&XIh9c|pw`sZk^x+6 zC_oXb%t(-I&HxmVSy55)4=Jn3xx%^EWDQ8TUGp4gN%Ng9Gp!2TQdmkx2E9-+6-;#PHS5?8d^s z<5fbapbc=)WD_pduV?R17Z_j0Qz`}y0rXU^Hk)r7u#{!O-}eJ`YUsmcjsOJ^*JLGk zgOm9X8}h9Xz^uG)U-(|`j#>Pr-U>B``<9fJ&?ladoHLA=m1c2u*}#dI9@o z)j2GSd?~Ky2zx7tf7L=6Cul>I$1)U9uOx7iT5WH-BY(CQ$`u_F&D`e1<5~z)da%lG z+3I0?1z~kpnh8NUOMyU6<=?GDE5dEHu?+X)WSJvA=P%CQRiH`o4V zeF>Gqm_R2oJ1f!aealqWeq>O1wg^xw9)|n%gwZc0mHFn3$+BDo_^BTNkW6+YmdNGq zh-+Mp;oJWAD4e8aK8%TUmY7-bS5jkRf$N)nmZ*hP#?R~Z4YuKN=dBS7T{3x0=aHn$}O0A>X7 zWMa$%NymjciRk?kNbrc}t8+!zMAk-?T%lSbXvEIEN2^UCeD6x+6YxW)R-b_VsuasH zkE2(TSU^D25XF3uI4B#)SJJgMQ&!~(xe-^d)W~`3WfFFDa~Lc;B!3%OA{;Q+t<#dz zG9(fzN)q-TLhklEW#c2#K}MPH0qor>7IWI`i8Pj-LdtAnOr-J-UWd64&uDw?qHrX$ zqLt(oKn4J|+=gtm&jejecv5fD5Ax!{)y9a%R1Xz?%_!BvF*Q5uXk<+63o1?Eu1)?Z zQJ&vOo)H<6y05xvDMk)!nTd@rCM{q8AK_+ZW5dB6H1Exof3*AQ63}UxByQg z;D{ZTu#yZ~tEg2-xEMGn{RJQ*$B^=b^w{!mb+Y1V{qL?OE!+UpBW zj0(%D@cO>X^PC!C$aj8U)gk_SaeL?YV24{z8=!K#;L7rL#Gg7&dj2Cx&HrC|^-Qpp5q#^DlFcyDKubise zeH{Dv*xJFc*Iyro7f4UBDAq5d4@*GVpo}jJ;xEnqk=d?ItW>Q=kFab`<%DD$6K1A)hAMKbilFsJ8%$@{9Yvl|QZ2(jnc5bjM0} zqaYp9DxgTi0)nt~cQ;CilG5GXB~k)X(z(0O;eOuxdEFTYWrm$)_qxtG-}wA;s>awE z57OSN6zX3*D<^z1F0)-Nt!MGe%`A zEYFYo=+xxDzg-fxUvA(4q31A(%R}r^yn-{MG=9rY^fJBmmU0%VlLJEdv+pt@TaW^5 z!HY;ds$@Y(8Yegu5oU^dL8N@nNc=(nYy0@PPXXiS>VjD9^MB5UZ89_#!;dY#e8E&^ z`}2G8%Zsn!pzCK1G$wYVGi!7V3^hL?0Y*cgqxE$vFXAN}!ugU{KZ+@&yw%ZQUgzS# z*H?L1w_>rNeT}=t>ov(-s9si5tA1kg(+H@~JtSda%!&(3)!fb>-W)fqYUw5Uy~ftM zdy&PXbNgeAi12reIqVvvFD56p)%_DD(fLX8H0|W=@D3yC9pG0Cc4!pD5f!Drx=wGb zz9b<{t9keCYW;L94)jAk+q@z`u~AtnvPmK-6)RO7grQnJIkFu!3SN@)5iaP1=@xz?ACn?21!gsFz<(2VWtnE8Ff+-!GF`Dp z;~JGF`ect(7j4Ds-6ryrsyS3^1dHQdl71=FE_9C=3E3qqd+{}SzpU^IQP8J0efLqy1BVH^(b?A9N*73ab4eHQh@40H z=JG(o1Kl-of)|aK7cah@x5fJ+(ad6(zmVJovp9qQ``qG+X}YC=pId*dGt1w>Qn<4+2W>koBpc^#*f^~?1s<<rA z?FU|zq-5_18l0x#Q>{PLousbrBA&5|gJ9Y|>hGPZ z*>;MTC|x)#@&LxPTg{0P~@nSv7bq*}+h=vq&Ir?=FP%yOjt#CKUJ zC`g#!GJ(51NFCCO{+oITiuCG^{(=hI!v9V$NuM*#3iGifa=fW9s*@kIA1Nu&OBmes zK>5qbs)GVM&gdw|@y>*`Xo)8G2yB7s6XE$1>`F#=uC$r2Hd04>*5tc?oKF(&4!QYs z2RKr8Qx7P!7vSi}P8GU_0B%B1!NBsXCL#OZ&t*7_zq^%9J5?C9Q1OI?|M^WHAle(g zLmY%EM<8!J-cK&HIU;Y^bFcja10U`zRnYJm{T zCy=EJGX7apYE+b7qaJT0KOtg$1e=6g2m%|TyC9UH<1$t_IvW4q@iB4klMCOWgcL=q zhSws)nddE{3c&V!XKDPR2R1Qd$^zxqkkGqTI>;$?iCE7eNP(RJU%ipRjc5G&s9{-) zC4JYY^~iVAg1pqN-i@!7FfM<8|Bbca%VMHZg&~16f6gcSUj2Xi_Z@l!IjD_|!JUwa zsH@rQqP7 zPaEtPP68p?5P97~FSTxD6B)joz2c+YD(eMGof52l3gw}zp^Cq^)KW0`VlVl1)fM)8 zzNYAID=EYYsh&N6AQD&m=laM!4u5rApKh}t1U<4PDQ*txgQQD6g8!3lJ#zW?n?Z)$ zh9saCzCYLdQ-!n2PBSN2aQod#Q-S>PdOSpNe*Y`VgcJ*tRDYJ(U;m0pwAdx_oR_LS z3^Oo#{=ew1g&xX~N2H1i@3(+uDia+1IoE9ECZ7;OFBh>n6jogKN9fs|^~mMa$DA*h z8KQ&`N>t0(ky0q`o=2MQfWPS|DoFg;FFiYeh>1$d{_!NmWGF8M71d`T9{=8i>v{hB z-MXyax5~z%n(GON#Brp%J65Z`^N7(H!?nXpb!bAn5N7SZ3pG665UW95L3X8T#}0{vFZc}nLt5f-C5c)0 z?Bs8ySEJ^k9H04VOu2+N{1MH>mc0s1=Jh-!Yq$Aj)yG%o#|6B= z`v_I^Og2-DSuB```cHH(|K!Onlcc>sncGya11{?CtC#do~Mfap&FT zcm{I+FY)kPhyGfxy)@4LyYK+I-!$S+$OpVQoe8apF#sSLiPpWpTCV1y`yTUoa#(>; zbV81a3nlrBFh^8RA5y@lYuBXoBIo{}uZE;lVcI8hOi+F132)l}#eFgR;PR$>u61G* zj>Xb~RI>8L-it^2B-;P)ksGHhDlQefG6A=q&X2w;TKhVUP?Yoz_xEPlm_bJ52i!-Z zF{Rd3{Q>@F)VaWmSk<5Nx@@!L;RmHGy1#e4uKtE}D*DxiNke(>#mYSdIqqRO_Y|aB zlB?%iSWBeWST|j(V|4Q0>%4vG&mJi?)Yz*Y#2ejUD@7B$Mqpls8nubTX0Dx*ucrAR z8ZOZ)y}FmwTapUUN7Uo5j9%y8zdl9gwtFHMnb1Go6E;i?NGdFKb8~Ow6L6H)+O?o- zb#vU`LjQo=`Y|9T5qhOavDmo0OGjCgM%`%@Qy()0HqE*D2SiLX8U&;Q`GV0lIyx+v!1By5V6xn#WcZun#LI`P||GptS(tPZ-EJw2zKH z!|dsoH4@O_;m|ONl{~5sj2V*vZUoiChk>#JA|fL90Iw)25k*kE`kmS-Gq6fvi2VHd z^LoXlakKBaZvJU&Yb*96CN>8QHP2~e*rtd*kPiD-kcc{#fr39EP(cU| zzg<7J$6|S$r2)Z+Hi}wE22jH+otz1_^~)@*owytwJYT1dw}(!llTqqV-90H=UTp7W z1;5Vc4%*thX#f332;2%FZdn7V-O5uS{9aSE?2onV&w)DYle|2DadE`DUFCdUD;i31 zy&HqNu6L_6dmi5xH~)jt5)wY>jm{@Xz$YOlQLDUMT3l?O5#r9&D+&6*X{Z17B_5!X z^eTnmGWr2j!C^snBdoj%#09VazP~@fcPj8uOc5lq2o+MEn^^?;7Fe*8NtjnL(TGqNn=O*{U#1u^k9myf%X*nNlA3=DwhM zG7NZ5Wsb}++-83SmD5~h5<3F4N?3jlpAOB;kk-{jPD=#n$eb9xR*$_(-jsTKBP@vG zj!wZQP;ZD@E`rl27QSb@yseEhIMKJTpih0cwx5X$RO60V2Dy9gTvp;?VSO9O=EA4y zgmT6mk;iLGLOH*F8gSkpP^Z-Ty8_L&x}bEuVBht7?$X7rSdDlo0{AKR@z-fjeW7Io3b8}B0 zpN&iFzWanwruau(@Vo5=UA%GN<|um`4GzMsP|6zlRN-jhXmscp?9-!Jx74(>v<)t6 z&7Mg(gaD%w1nTk(ra#??yk6-zcsw@OohOwcJBQH?BMOTOcY;IKM-L<{NV2c9Il-|a=0$m*HuiP_av?$E6-$Wn-m z7r&(j^eQ#CGN4Bsoqkl=Tv+qG9980X;u>2bE>I&nkRM+@Cm@V3jlU}?mfe#*|S=nB;oJ>92dV}ugo z$)1cj^*`Z5n+ib!Ie`?Iv+Dd0mi{mmO( z9zGFwi|xPb)yRlr@^P=YR5^~(!8IIfLuaQHdmmhQ75zklEUU?FA`XRfi8xoPgdh=t z50U@lkFU1HfVYa?x>sGrA9W1)am_>pN-+x2Gz-<<=Z>2|Q0#nA=Z~_-E;yW%g8KR) zey{P-W@l%Yntm0QH1O&i7#L`mR$V?5h<`_wAU0w-lS-m}sU(6=f>6&;bwtURJij{~ z%QkJ|wH>BFN5@#p$d;P;{(`GeE5~e-(K_Y|)@Bn+ud;`Tk0zpxHmEXF`8jZJ00v}A z+VE5Pt~{u7cPFD-RdGVVT~XsQN$;xEr78N^c>sE%TjX@Q^_r}o00Q1u#C^Yn6 zq;~;~Pq|Aun_EKb+6?}m zjc>OLOxq&2-KNB4e4|GT?XsS6P_R8W*&^=AnM z(;S$WO_i7wb4OK&_206L(K{4lXro?yHLyO+6tkcImbWI@M(`R%B`LG+g)lQSv;TKK z*B>Xq=DxqofFOZxp5B7`9%vxr)0xwOs1_y$E(!0Sw&)juaTM1%&lLm>J!ub?8}B_q zK~Gwi-s`@r2gl8*)s#Cn-KR`&kV%pQQ7PW{-PlnZT<~FYwGUuNcY~2s%vDj$S0S{4 z_@xz`chr^xpDr^k zTPYKGC$4A(nW7soPJ}TjMav_+&%aqr$j&d!vv49s{Qm5{e#Js`?RQc2!+y4$5|`vD z{Y1BVTI$ctnyWrlrit%b>Ei}^V)O|mng@|DvcJZOsr?Dg4)Qi<%zyAu0mQz7!AXX` zLTE&jc*3YW4fi&>)@cr(O)Inggp^CWMDvLgZNXu6EE?c!b)W#s?!}jvJ)jECQfm+u zToBN!>_)zksjBNf+fWwA&hh-pGidfcS9Ejr0<7XXqXJ@@;k!xY7&eZ=cxNEh%F<_( z-cn3H#x$vcrvMr8*IjSmWoO3**_;$XJ>>3uwe@=HJQi=nEr^q-OtA)Cesef2wvQex ztiF1Mj9r`KHyrh<@XJxR~82&BF@o2MSTac>(p8#z4U`)E@UZT!j0AaQSe=#xA!Q7F6gR z2#RV5^Tnb5`bWj>;BQZtReR5HeyzAfIUKey)_K(E+?06k{D*M$y-4BtFIVtcB~T9)^x%89 z(6ieDM)*bk{wqgj|D7|n{&RuFdr)KC*rKwPY%9v|AJmvV6J#ph2*~_bZP5|L_-UbG zIWtaskL~%Rq4#c4-Jl`HV0342l%ky9gxR3ztdTE9$3t{Z@tSo4WCk!g+;0h%?v3jo zFaMcOnCBpeApFH6;-aFdLYF%?ISV2?CKPmgm#60n;LZ3q2A!*Rn6gcbjMgBGxggHc z0nAl$>%@nFzSk$6qtYQsTLC&ZKUA0|jMkBJmkv?#WV@9oCL!gV@mJ=sc+?p}{dRA; z5hOf@16zDXL?EasmA;K30vb{JUHQU?9So1<`1&@~W(qd7sYPAr@8kDgr`rXVpD@EY zag+nGo=RB!EDL95rJt$rd0}Becyn>UeIh1Sn8EMeHQfs6Fl$>8Kn-^=6^Kj-(9tVG_b(Jxu~hRI&_rxaQNh9r&2^mNjOWjmmc#TlZIcEl zTHB8S>JlnZas8T$LDJUq?}Qz7l#u+#%T?4W!|_62EhEHaLY2;bKL9 zSbDD>v_j|9|BL&zPQ;|xIlz(5cKe?p3f2P^gg7J$c&ia+fShHoG(8D|X%b@{bq6pA z(u+0jp{BS#hQ~=ikR?rwheQaC>CV*a%DkWP{j_g8iNVBbe{v5(6 z`IN@J&fP_Im*i2B=;$g~l0YmxK5+r;ZM$Y>gdBakEs-aL#Fuo41NK(rPie4bltGF6 zyAhGhb?-g;gya;hBuAitLJKZfQl>bxEYp$YY1>FOeK#_yFyqAR|NLyJ-h)S6feOwf z7}rf;fsky^mV#mC0Pfm(X1`UO&NR9qG^$&tK*@6CuTZL_*Y^Odw36#|hKCRfq{<7V z)ArjMR-K8lH`iqzbln07K}9RNQzrQFoqv=j5&luVv+LphtNq(!C0F)VpG*8AwWOee z0%Bmi(AqFlc|i*Z^zCuTK+&%a9z^EU9CMw)Abd7J_mvS2w?`&FU81?ZUBCV?@I2N{ zuVtqg&Ym(I+0!Qo@hAWk+?QD>$uVVOW}F{|1M_70dX?Dx0>j&M!TaFqSuZnv>VuuMYk#TTV%9^!>)+k3 zZ5`>|%>1wqBAQV+0hC0vto{N}1 zd1zv-^PeatD#Dj(+wAe35x;GQTjZ%UV| z>q?wbDgn@~d0MteJ#7;GD$+Jce}0FM(QyYf^M4mBO#8>2&Xv!IU)$8hr7CaJoo7`T zw;duTqPlCHX6f7Nw5%YeZ4=7*X^)XW8F-j@voQu`PVZZ+4+wYwK6(lP(fqIb1HiJ^ zVci^xZo_Xg8YJkDuW&a!pZ)oQXG}-j6#HjajRp(`gIj>jo!<7-n4F_378RhGO7_O2 zBpw6sohsL(uAiTf7`?oZxeBF)_q~%E6**8Fe5URgIw+sLG@v{w?(!E+e0jme$8Kt3 z;H*YxIAY5ehaecOb&{p&qfX3vd2^SsleYLi&uD)IeAp}ZhJ0oY84qX zFa*BX!cQz_O(54uxVp%}#1p2^dwdY$>pKnq|FW*9651>gm}mPldd+rVCxl6@Xx{ps z5AI9NA(qU4jfZ`_+f;r!@F*7_i8Ns-@|(hRZ;*j9uJ(aM1gm3X zt6Gks6xRi=J8Nr!AkCj)fGRxoSA1d53@QISSj6`YZ;+F!^bG81Fa$3D>vcsKF&%ea zpBh@@{dAyNbsnq}Qu*xZj{-6>%T1S{Npab>NXR>?u_KX2vz15c&Cp5ZAZUE$it@kn->0Awe#1O5i~-J4Z_>WA`Z3M6t}ZQ6OZi-o@N%P3_<>OVjn{Pl z9g`D;CBEUI%{fD6Ul-DH&>2*=UA6{EyN05$`HGd-=;@8X0wU9La~{iK&HCy4_U$}3 z@4983Ywr}?2jB7WZ>orKjfB1%4gQdhNAcS?4$SVm%ajWr{n>6hA>KzCGUA5X-lyM^^W3i_NuDV$e(o+|@}}vrh{o?zIfa7^=T;)+r3AJ$ z`{^C)ns+NyfP4OfbLX>?e88Z5e;1Z=5@#)Q9rnM=KF~Yp*|^Va4-^l1Kxma(Hx3T0 zX+FBSJ;q0VBz*K|tn1uKM7z#}@@!{9kD%y7Q)4|W>w;OFCdFqp#;3yWjGRU1QwAnh zLGB+F_54#i_bHHzu>k#%`3B4XIEmiAbG?qSgzGvp z$TEEb+5F$&KKzkSCE@(M1WnMs{rSD`yINru1y5jmv>0&QVy>QM#c061k8A{0mBdHa zAU=cs?r%e@+uae=yF4_57V7?(N%|VSCxTQ!R)#wz;A8-Cd)Z^Z=~z(CXW8kQku9%> z{pI4_p!KWouN4avqb4d%jXC0MHH1}LKSDBul>Q2qv7Ae;tbS=}Ao-Tj@CSoF!fTz% zM>T)1y8-MF!A2wIWNXm!FUUgura)jlZm$DXyz=Y)VTbBaqMK0wKbEFl%`~Tq zOX`ddo33;eJ`f~DHD7gaTA$x)GtAH)?A@p$`_^IrFIJRkH7q>3w_sd*LvrO+VQD}6 za-&aQW@hr)hC1G6VtKr*K-RM(j%iWu5SOivG zm|WTNY^<^&Wuu`VwZF)73}3xx)xFxC5FPfRBqDmI;SMO10CleIBl4vLQYx zm%?Y=>q+ZgDKJJuy;|fo+XzcFg#SWbpZ*y-LyGw*t_NS^QGMF2-XLi60Y#hTmJbGx zMb5+>33U#0LV?u@!kCjK`UCO(St2~XsarjTJ-xl{LqpV=0%Op;T75`GFPTJcRxxw@ z#qMND0{Tm%ANtG6Lp!CVqAU~Xwst2{L*`Qy7R46g3pq~R<1{CtP9u5oso#D!5;sk( z6M3{cr#INH<dL&Z%H z1wiC^dVSFpP|Kj#CqIJKK^&C~q-P%txd5Geo&)o_?LfIj%@;2(A10r=H=3Rd8)hTk z=Acf{eTB23)AaIf6YsOAvc({8vGleU9G2ktE5X&d2(mHMos^VtciCIwBZiTLoxN?W zUb03bwh1D{a`n|u5#rmHYOV-phP2x(4nTscgF9w49$ zt6E6zA->wYk@UGJ?-r;sY}A#6gYS`T@dz@b7xYDUoY)LafMR9y>8J#nCF<{970ZOi z?xgeY%>g|M={FSkbYhIzB%IOZNyfiDhtznAxkj31(T zc6=x$OUoesg*I5*YuQNR{f}YMa8its_s;W4P;UPLFWu@1s*sPIqOPdiPnskwY6vw{ z;bEJu?0(h3hmu>pS2N3|;#usNzM*GxUOjw@2Vz~91NF5>df)Y%BQOV!hv4iwy%W_8 z81Sp_NGdViQI?#MGy%4IqIEorT7S6iz#SMIV&f}_Y}Wlo z--{xDl*aPGw%n*uHBr)ldUb$VSqcA%;xVL$MIbBc;x6T1P5efc?u{G4-9Odu0Mv#dnFFO zSQWjMU$b2EpYgcL9-PG|3&VI2bR&P9a}!his{+o5j)L*aae8vDT-Z(*Ch}K+db}Wa z->=)Rdz0A*I#5KEqz<`lPOEdSPsN|STWyI7`-hD{PJXt}vzxfeZL`ALn2RXok4{as zH)-=Xh4LIe`Vmqu1-otyB=Z&8?j$**kzd{oUpoFHTU)l6hZ0B%hz%up+nKw5ly)VN zNE-n9#c5vQZ;ooO5RD=r7>q94lk+i4UYCJU(nR;VXLX!83Z8I{Y8&yS|NLK*s#xxaccKyTmhgLC3P zU1W+2s8Jt3!^Gg01tMI|pRk`Z2B*yYv{U@d0cI4Vea(%%c~{XS9I5{1J`qlcg^2J# z|2M}owk`BuQFIF^%%Xu(IZ928?Ks8|y0h)RI+6yuuH^d`cP*Hih)y0IKU)>{I`aUz)Xi zFiD`q^8^czik()zQVAfWb&6DN8mFpE8b9BUitxKRBV!3&m4F>en)x7JNaDn_f6J4L z6R>;ci@dfg1=%U}K*{)Vo%{zBTm#2^I%IfKXTOw`6fI}>7a-Ak<@P$S2Qx8%z(9trbe+e7lL&sb17}4%S4g9~Nl0tEFn)B}?uo*$$!; zCgT#3)&RP`VO0Wqw~I5fCSJ!v-0zRz#nBR5OB33km7gD?;f>( z6QOkBFFbzd%H)z}%)0d=O&Z^094yv%fxg~-r9RMOa}TQ5WDgstZ)SFCh~ zv)DuyYu-hHJoxWZjvVXGE1dUm{)Y;+AodxgvL{vH7F;_1Q-vk5w!pCab|9heuwFDO`@_u)~=Yv8Ss+d7NKKi90(fQ&mH~9Q(JH_1GhVnCJHFq=BNb@kE20HsAIm zT#5`zqkagpi{5#7ho^37R^>IYvAM3`>}_O!IKN#iZ8*v=D4@C6?ip})mFBq9YhTK6 z9_R8jp(Z+g+*y=KiFG>n^{eYyL=?-@;TM(@nJzSaQ^IqBW(h5t<`daE6Bkpf^C2G`x(yHL+PYy$Q*$Ebhbtp*ede3tj{}prqGk;V=eWuB3J=GBiy`2^<#S0rh zp7$fhwT@9rF`c~5hbB5fn=Lfd2{rw&+G8gs!RDdOq(!=swoWQ{Gp!YK&$P7fPPey^ z1W}jVb8)!lFI0NGCz!_2d~NH%*Lot&^mek?CRyD)@ZC8EVp?OAa2f61nwo*dxHQBBk2L%P38_}(l(DT27N^ll@)>n+`L-f>z_1ij9meY}#8RuAPjeyVlb zA>sC`l~3y4tOR{@nzLN%R4COsHKl>Nnzz` zFaEGyU7yc&X=E^b{41!aWu;5iRy#D}M#=F{jO_8#-6|Q$Gf$6qzbJ6o(s3? z&=;8Ek!ij?PwWSuiF>n@@Yee-9#Q;2OiD@W z^lrtD?8h}~0DI>s;u^*A0_2>~p8UA78I7j|V9BTw6U6P2*z_0EM?eYaU2go~dVWGG z=(ubs=_pa>+}F{Dgs?=V4PirHwRqRwrNkytPL&im)_$>IeP$FVv~*8fi~A4spi=pUw{V!+8$bHkic&TBvuVpo4C~%Zf!SB4%!JkH5i;3K8L3 zE`8AlsX|V|$vo!I(zFk9prP->tD#9@TGEt(xw#fsMgKn4lgU{%#%i*g*b=gc+~|eP zJyLd^y%3#h9f0$Bo^|s(FDrYW-v_M9bc-VODg|{#`TP%bSpWSyS7VslU2HCW?iJB5* zpFGQys50q+N$}XWJe)F_sM$3Cb33ta@;87+?E3&s?H^Ux1<2Tu5(L=Nj%P03Wx;9a z?8tee^5Sh?yK6!VHM0g^$5*a21b6u%dq~zEd23mT3B=SoIVZ$PtmN1^0W%$NYQz4S zQ)Qj}8DR22V{qIodu#ysgrcn|q|e#k8MRnE6Oe!I+}|al5w)j(`P7_2GG^<+U`kbh zX_E&|%%ozMa}=cn=ISs~5whHT`O61QroiK~89pQD$>zvg!e8sd6>u?_?J*Ep1)^!B zf>=5tj?+CQGD~vKKP0%_t~P$49!VFLn=ep`pNWS%K@yN~4Jdch?jR`_C_}riQ!QOW zle!7^rtd4Xys!@0Ld~Q>TWo9{>PO^H+bdU^6goCm)G7B6m%oUeSJGgkxeBLbS70Q~ zaW8dMf#L|2{d{g-yCRN+ou3Y8bXfDhH|~Vco5=AE8K^hjkr`Ltk=|-xB)@jM4wf^xLD_ySguf7 zVD01lLOxOjSrO)@GFX6^)i@mCeBsb_x-9p0u}(%^|M6_4Dbw+%bkE)gZ)`=ZA9n(7 zEb|7XK+a5+`4~mw*pS8FnzH_E?j}h!8<*Z;N^E?y$oU=Z+0*=J+sqA}yK+G`2w{&_{WYy^yB1qN{r z$2iaei`fPpCY@)Yc+}BzzdSXxxjc@RW#*ol^4b5RPvlYx5vk;pu6CMx)=5AqqQL&A z;F~sxWa92;$<~>QTB41u@;7lL$$t>kzPlaW4=h=3!>NW1%Qn+ITz@itbdj}W|4ZK- z4QyH~R$wnF>#(w+Kg8kGBDwE-2A{2>(%Irv8Hd!;WO%rDR5l-5zlU240_T0O^#vw} zUQs7djTP2dyR);OB6&R?Fy!5NBxeAsyc7U6g?oH8=sR3#(rJ_Ni=-4%l=Ka*^Ow4H zl9z-(?@=XXDH{gL+6RLKQSIn}x`oe)~f8 zB;8JR!8A1ir0?~N0oeOfOH)dt%~hJqT^_Dr$ZEz|UA|j6KPdoE?=Nf=)vNQi^v08(_Ccq^6 zarKm-y3CI0S@8hw$EV6&=#OrGZ-`=~Bfw+?CPRNt`0HQDhx!fK$h%2wIbUc?@auh} z2cmfazzZkjdQ#!?x*gA=kBDWq{0yKxF#N;8G zLy?tX#o`hgo7J)m(w8Sst`DE_vG`o(hIuj{yqPe{$P8_KRqwjWno3*=x^(1P*(U9( z@#r{FXFlT7Q;9j0LtE9&QvP$_n~dak-p~vqpT1M`w!WAyme!H|U*C8yh*&!8)~Qi$ zU|h!ixW;hcax?MsJUfClgOitj!YEMv+R+-+B8+OY zhb9b+%)j9r1+Q z9Q|q`q)1imeC@w*ApkZvT(xu=LT`fr!&1{7$x@>XkT6t(j7?NWcp<2s#hc$&-6~W!agKZ zAhQNlz{WY2&EwrM*{)P8T~R|^wpSHNQgx10E*%TH!y0>WI@uG8kT=Cd7@h}pNC z6Mt7KO`AlutO9OjPLn^)H+k?F)xTpo4$zkscs)$7J$CP8$)?R<2{D_<*=;LZt7j;z|Lz;cr<4Tii-E|x@|7)A!ED5Ynp^tky zpaiNK^q39;#Q~HUJeg1)SM;xK#(3s*P{Fs8hLIEiZyAuI(o9Nz-p)+nC_UtaOZl9~>k^KMyJ~cfbk>Tf zJbmF7iCxr;hbgJz`X6&jBwZ!{Sz4V;r^Fx|mMm(-T$G z;S0=cV&SDYy#RBl80dKktCBfwJaTmTtb(X}=OOD_G1*mBIh5fMIF_E5V5*&gKM0ID z$SfQmU7u_b16l1haclSO_ANGtO{uDdg{nz|i`k|U6*4t15to@%g0$?9yXQ5>^0oWP3rL1Y0%QHz`*FYFs1w1* z^EGWYk0Tl(7HhxwybM2Kuq5;U9>w$|x+&c+h9|5f`h@aobPAQIXK@Poms0Rg;9BO? zpttJ$tf|H)nzA8yB22>cIfn4_kfJkms!h*_JJd{A3FI2!Mu#mJ3>c%u3ZS)9oQq2=St^{nSCaejuQpKN#m z6P*q25xJ$(+{{dr#KAf@b8YWt>8|%jN#zYo-0DW=RYK>gxqY1WNM-yEuW(-nd$s`# z@7*93myDJU+J;w@In&phRx!6hpRAp>pZj$yWJ6X zlTz(w^@_?vDQV|QW=+DYP_B_zH%rZ>PkR1%vZFNFk>uMd%*$@oL#p}tu+D$xb{CQx z#Xe^{4AuVWY&sLDh4Izo_^bTM91onRh7MYVR-xBXRXrq-6zCJPLzhD+7SKb7GrC265VzSbUd|i4?mEpGq=!z%BkB9tg zoO487rn+-!LXwy2->q3HW8djrsl|$sYIW8Sf6-wtQi#Lxqgd(}JOX*2IA#dW40uvF z@%Wb_Csixis0{_bv816CjK5voLW2oA3rzvXKES{wMBe4MYe?BBs3*zy9`@RJUL+Dp zFS%-~?AvQYR0uqhy6q$!m&^-9BDUzTMOGRt3#3_fYVBknUjE3CPFNE=C*pa6sIfY% zuc%*~v5#sy%S0w;ckhe6pC6sw3f!nSX)IKPX;HVCYOO!|h75M#4{4Ha+I3NBeD{V{ z686>}-iX?;V8$71%M8l!=0(&>#iyRdG`T~vk&zB>C(0YUiy^|cr0>4$IJ+3INFq!Z zpo$G;-OQDIiS6TU3}uH)$3&{>~}??mM2kH$zL;Mv{9BN-cs6{+3KE~thhl`|6aQc_bxJ;~w5+sJ0kvcu+-HzfkcF-06Ewco3<&4kmK`CAUYu9GenIZF9hh^n^QQcU&Hv z#F78Lb+?9?2VAoio!cpHw))+wV9Kz5eZO;{y|;aa*bYPSeP9ycf%@NJbGD7yP~9Q3HE&_`-=mvf$bn=xF^XTiub_6IWu8M=TQ^ zDNpc+1#XriRn!?b>KhfNub!Ah&f>h*hkV%X055Al^ZD3(8%_&yv`Zsl`)ZLR&!eb>)?@SzU?~?c zNwmdWx-FJuOpB-YgJPJMe)t4=b)IP1^*Q%&U+8btpE2`ar`It5M2Y4+{14OW`ozYt z&A(-u#Vz8wiW_ol54r8pMJp8#F+*ibgdV-DN>;C^%dpF)Yl+`+IeubaM>~tU3weYl zpqj)=8uSJ@86}&R8y=m}7RWHFwv{10J@ASKm^fxl+kE3^k@YkcMDG@h1U};lc|vB8 z9!7O8p0sZ>p(Rh=E%N_w7Qh-ZbFIN!6}D?6W{M^^0oB<#`nPOPK(RA+b_S?w&&SN9 z?rB@w0*}9*`+PZHs&}RXYdAOBQ>n(v*F|ocUaCfy+e~umj82Bn@XdlmRNE|JXtb>; z>@8Xm|4fo3lLZ|>{o%0+%$fL)f z5TS{@xLw7?fVd;nlfXsHnp@PhUyO6>7rG==w(=66?X@Np#0@rlND(=zOP;DurvOh^ zl>HVcCxkR4%s5|7oE#C$ub^atDBr>D9WcBa^m%_%4UA-K(w>QY%J`Ys&?~S#=AC)^ zXS4^XN;3DkVlZ|4BMQoN9XfD)PntYuG$=RWU=evEGPVpo>|>V3;8NMI%x4yMik@~b zc>y8zdHokL1_nnut;N+GGF{%pTsnIFyOVUa zuYb3yIK`^rvT^fqI0H(sHDvIw+fsUpFO3Txp|cprcAOSHdLC2Vy5`|Dn~MtYFEwmM z3nJ$s%Puuq*Rwzc{&!C&GJ_#Lf)S;w!if^cq3ajqG@S74vZckGDu?y-kcgnzDWi2N zHkD+OZD(;IA^+dMb6~3OW0GDc$};W-M(=a!1f2MKOMI_S)?axjsHo$g!qUHg*Ajq{ z)g4UMa{1pld`(=xUPU3d2WJ!Pa{k=%c*Fk3-eo%f<_>D0fd3aU49`+X(L2>;Z z%x3_&{>L_hi5>UmtIufWMVIHy%|cOt)Quixy09PBA72S9A;;PFVM>9GB+BYK)v(;Oo(vqDJpMjANj#PiGUOtV8aq}}P_XQc zOiLAXVEp`;G6>v_RG&B)ES}P|>G;Q{cE6r2W&SSxl4@4P4d-3@Fm_%s6N%@96dat> z?ngq$O8K~#o3-Eq(x;BZ2Bmg@5Cw?rM};yF5Y>d8_nE;k&0pk68r zVB_H_9GSKJJFREoQa2*BN8)IJ0NUJFnK)x{qg8@u$v+YY&Uc9a7M zyz7HAT#y*U@2>}##hgE}@oAbzRW*ti40*pq4W&HG1FN7iB}G_B1eutn%tiTehL3bS zEkf$;9SrF;{##|3yC;34ezOG`N2CLa#XNw)3qvIyV}|wu}N5RWg~2-yKj4 zG9?maa3|FPk!DYy+xDfUv(IZeAOD@834W+wGk@%3F7f^bHZwLg{S0Y!78A9V`LV&{ zh*tQ`{Da;y6xdq#Cke3KH(xN%sl!sbh-Xn=Lj=ppfWF#ZVJxBpqU>zV(Cjg&XeS^` znUeJU`{x20aum+3*U4)xp2({MCxdJeBq)*R18SeB%kO~APXP8IsyiQi<^AhwW2fTB z(?H9gB!BihDRsJh8FI{FMu*UM*<@-DDGXluV6y^%{hP((hVkaM^xF3$bwH8jbUx}>h*aIVx#1PMN3el?CWxO~-oXqO|&+!>FOO%zZiMQu$8oOeI{Zpmy% z?;y~-tN#v{Tba@{r%Kd9X~aIz14y)YRBU>lN&@NBLvfz0hxvaoir-xZt+ipUXm4*R zbZm$0YK1YhP)+FQH27`f(@OaV0|vK#r3oc)k^7vgT5zFlB*J*1hyS2z8;KIzb1R4h zn!}jxT)MGgAo2sy2lM7Y7PV=UdlE0nAeyAPD$>vU`e(Dl6;H&yod5;K6B?hGCMzuDCQ@?P7JtNJ#*0LVGoGd4{z$8g=AgFQxJORxf7d z9MO-5!Nze9eXDj0jU>|CSRzlX4t)6lya_E;iLJlyIA6u3+6X1Bbg>{nD028zJYLq- z4)rr(9|#bb$?Ds&eA26q1rF|waUtceqYy-V-vM=4gk$AL(|+T@J1;HKx#iSL1hYm? zH1-}}p7-cB2!ed+_dFsjZYAH>BxYp~K>}ssIljncuA<(z;DKe5$N|3Zbh8=t=2!xu z#Igh@)h0<&fQ>`Z-W8#D(p{m9{ttT9TpqO<6MEwG7xo2xjG0CbL$8$oGlDsuBePL0K>o_z8(f|1^TT4D=_gz}l3CL)*D*O3IP z0E^ry5um=3d%RP6si(bd#&3C#>0X(*dJMlsqW9*8(7*is4Ff~*p^MAP3-pfZUp8)w z*atq@QkSK1IlaNl5``-y^2MuYyOR;KIvNdg9ll=ucuLl7ApO#Ap@d_`R?#I?oZ<87 zMoHqXh>_o%c=~zT$M0LcHIqJhzkMUr0|C+qYcVdu2uz4_c2`cn;c_o9eKzK^o#;E> z7}Nq7KqVZlM#Gm7R%23D?aNW`wL7wJR7n_APaBBfp5(iu@3(zwulL`_PvL>X9vui8 z2EnT93RdJ{Dg_pjDBb5&o8`>XF)IJ@Sg-aMJy7AN6uTq=`1aWQM8fUQMlHUFoU)#; z#+9&Ov`(%3U`X^7r1a7nWK`&u)8#)M-dfgZQZ7h(UP!$<%8NwnS*Gw7b_oYlXgk3ZsA-8Yehr#QS!VAi9$k0Dtv%+ZUH=PVGp`+Zx1*on{n z=_i>@?GfTv5Ao87>y>7^|BrQmFKJPE*bjx= zY2JQanl0SKCAka>P29~Z{Yp}S^b}4j$c;kVHGW#Bd!z9eDk@Ye0{?yclc@6k?`4j0 zFM|2Mg9oONoxAB7aHd=!vo;*qTXp@sBDKzewIa0*@}Ixzhc1eXkFZt!*X^+&*ErE2 zcQvC><5LC^V^le({?A0so-ox#Apus$7!xcOWZ@-9R6Ha!@@0 zCa7G8M&6a37EZ*qL5@_BYXPbSZSQJk;sgvYlRy^;)vv+_FoOQ~#T}AY2NF|h0h96x z@CeESNo)3gx@<08xZOsH+U5C2m!p0XGev(5TcF0(INHgD(;1!rVL2OlKH;e|$@;%} z1hiN$bO{JwHh+Hzww%2o#~TT~E7SmFCuwJgF;lF<q$c8UTD$!aI&|lBkQ%P|cNR=6HMXrj0}bT;xfq1yJ(G_n4Ltw5 zFz7orcZrMez@QZIj7RX>P0@VY^z!q|Iyn53D1m#O5v%5Jwq*7j>2}^Q09Vh>ef>6o zf$3Pd5o`}sbHvE*Jtw0~j!l&SUO~%Sq!H(};!kqlW}2%s$erE&W=n(y0hh$bXuZ;3 z-(HPaZ;pSQS1qUag#!J{Kr~e_@c9$~k#dXgg@oJINCbdAbq_LkqV!0>?+`+Ohsp>1 zv5$bOPHN~Y-s{PnM?mBh5=UfBW3M@U&Em4$8sTa+VEJ_*rT_wLrj)q>A_O3KQYCTL z=V~p!@;dYcFh4?(V&-9C2S_upjILZrOMMT=%>A z+svX>aH*5YpN(wy(fn^B#44F)_o`C#?8Sy7a^eTd;y(QMH`WHbX@X{#mBjLspluC1 zMU3|Lj_Ew9M?gM7{4mh4J%l5&1xV?e%aNHK8wOQf1zqwF8}Gg$XBR4#gyFha_x@HO zds|P^fJ$Zm@`zU02kY1F&q8$1zsoT|Rv3x&pu5y+@b7 z2UA&knGe`U8f$UPYZ~#w?o1$|ja)60UtUu3Jtm)e>x~eY66E>|l06|FQ&3f9_qo`M zQKuBmfEg1WB30OtUi;fm8yr_2dO0ukf&w2c#p<)1fq5Nh?x-3Ixn9CAQCVF)_)*jDG80YcktjbX|EXx87<% zaRmYx;XhKLf4bGiHWMCz=^nR+9v;nF5{{zc3QBr=kHn4k=#_1v3514jCw=4L9kp$p`_<6*X~nSuWp z_XyY`$fN@Nf#DnV@}|%zj_Mu(_bASC=Eohl|1toZfDgpbIUPRvI$^OG7)2o{Qvp}t4E<8H2HJvKP3Hj>m;o%zxBa ztdljAv>1})JY>t@vl;6iBKjUfeIhF92~V`MJ?)G{9VjC?waMn}E;D84^(Rj=FrCY!qP?vIvaHdI3x{z}FC zg&1BcuKsN{9PuyBjK_IV9~?^rAQmsMxw)C_E`am|4rQ$ly>gWARu?lrzZ$a|BD+V2<+pi)d9OMx*v~Auw{WJa_Wn_ z?Uh%>b|*$)z&$yqDd6lf8wz-5QYAIMhF#^)0{DCdW2tV8&d4|%-YZ+y zZ;$uq^&%n2`OikoRDDv9(DSvoluvGdc{tYCY2nS3s6>H~`8?p`bZbbDF9N{tOZ(AR zMatRAFqfaa*7-8*okksx!M-#(g!8#xl_c_(%RoF%$@(tAW|ISoI3pw%a*j@*R}djV zKkP$naNaG#&7nYU6TMqzhfOYq!C}}GO})Rfdc)t;=q z6KxERmpmoOLF8IYstj}45PvIjga4RePF%R8WU8vI+Sg$_UcXyt$L=&brMw?61DT-$ z=-;qcPKexI?U=0#v+L(QxYv5U+ndSo|J}S2ATwWOqSc~^&u&uJCp}$<^rsRT*nTGN zBg^?2aPk6CzK2l~p*fF?Mah2Td;oGvw-$jd48Oiq#@kq@sQ zRsB@+5V7D@h^!Dfx2q_E!@D205nJt3DPnXr=SPaWZR}X}-%uc$U z66RavpW(QJ18Oz(g*G@>DwoLzQ29mpDP*kgSKE>Sy`gc34<%5w3}npOhE#+02#)OE3n^`-%JEVjvr#sgIKfDsD9AYsrA392I;MI%Bd`SbYrrAsTHon+HQ8_ zpwPMPLr{05Cre35S-yPjr?3*>zaf=G`lP2};XVxsoHaMR7htf3CdcPky`Y=3;k&W^ zR4NSIn4%xrjeJPhJ|zU8{>Eep_gA&7?qTMT+EvNuC`c6mnUXZEJFJz3sycq}0jNQPWzL%kSpu zx(zZF_breg&qNuW7u!3lnZ5a{-`5IELkR_PQ>`A3cp_xzLTEq}6a}W?5xj#8K(g2# z_M%5i!IaK4-dzI2`#5TyYfQ=3J#RA9M$`w;7-t0ozyPysyLaQpg3I zLmnb-qSo$qR}^?)Q|88Po@y}G$=rI|g`dJli#$npAT>d=!Hx%@kh(wc{{BPp-8~W| zLLm@UhhR@`q0y0<)9eeKW=3w4bARo|U;>X76NEz>HGuV2_R2ET$!67Yt}^3W(R#6V zz0Eib{kXad=RTNtD1)B)UicTLJO^|-(_L`rVylPIIt`ehyq6ArLJ#zsu>EnN1R-!x zx!?`R(e5-qLXW4llJ|zDfVj~SOV=aI!Xp`}Kj4iDu}(}A=5nKQ!+H$tm4g&6?X>YZ zAboj#ctc?*MO0`cl{Kt4)KscuEJLgH?Bh`Git(N*P(-#1g^Bxw7*YfHRxz)$+NwpX zr(r$xa@D{6!Zho>)Z+)6s2eqrVyaI6u_@POM^p&wFX3~5}*rP(d zn`8QW<5TB&$Ek9@Uc9)GpT%skQh8XCI2vjwD&<^27miFAHWBV5Xx@Z|U0+>Cq{U%i z3i|9=Sy@fB%c^Gjd2; zvp+Q^kyx(^rYkj&J@?sU3Jxfq2IQT{Dmtum`i~#b_%OFHfzYG+?tm4)eU3dUa^grM zA(ud&t7oEDl<)>&)0VeVsFMJ~Q3xsmw`OkV`1VhRjh{$`0@|krQ-hun5^@xCfY+UC zrLZo8UcvM7iY)K)!5m-?cUsy1>2c$sx-Rjm=Xe! zA=RDdpQf75D2g}!V#cPpR`YMqoQ|oseqzO9AV#x$yPi=L_(9&9Y2Gp_GO`cIcBIhd z0KY`D;+0dv?2zwRvTU|GwrB@5jJ)_1OM6P@j9YLozicy44>1q z{XIw&H*7TLJrA8*l8>PP4glAq6W$2c25BYJb9yKOg0GbTYrbxCQ_|)+ zpoaoZg;R)@68ncV5{cVg`Y$m1HMh`!IY9-t-Mdw!zu%<=C4fFgcIWfFo4vx4WuTL0 zzbX;v0FxRz(^bIpx0+jr<+p1BEmq6LEC>T{*=iG{)^2N!{*5P zuSUSf-b>)pdNapSzxZg_0tLm1x8 zns$DF|IKsnS5)`w+q&GvuW(yTf>RKimo^Bg8M9H&JU?79s|)TlLQt*&%KMKl97Jf7 z)2|W#+Ba9c?Z{vIFWfG?D7W$T}MCIcv z*y_Fgph2HUDKS|<<+e^2th@LwLKZ%d8Knx6zqf2iC-uNS!#iKE!vc?wb1=aD2boF{ zl?ML+VUq7l8W_Kcj-+vgDW|YS^bWSX(P2zbYC~R3h|+CLPq{=qYjeB8BIkcYW6Q|$ zg7oJi`&SzmBtP%8lsC`!j`K8y?!6Cd8Ip{r;Q1_Gq!^!L9e$m1isrp-RE! z+p9Nm>n?Au-MIhFHT`GeD{I3sunNWOrjtURYon@t6!?lx?PvZNy#P-`<@x8q5V3!I zOXwgLDHXo4C69f*O)aSM%d0oY?qBhg?2sK`+$Ho*QkPC-4NO8242PVWdGC#PLzuW9 zqI|yYk0eouvfvYSSyWkr*<`W{j-X=H{xr4S6q8$6tTB311+PA)KAIbzl7v;A4;l zT!3dOO0rVAC!q)8KCAOiU5f1`)-jUHgqu5{Q9vvg=RUQ*U06`iFWK_$C$E%JO~}9s zoSN_}gT>n`Gat;Yk>t=WI2J0GDZ8mLTjZt;zu)%?Gu(?k%(D||pvdBZ9nnZFau-^H zbUP{Cv7!hg$~pZwhDRi{iikN3pc9$)muZo}T}(bgDOf~X!R z?B;UyxNtChx_>Bp;O3Llf@g32?v~R^6D3mQ9bT97N?_W_4#`%kW1Cw)*08R~+bNpY zL-AVD(g4>-0y25<;yzn1)LB2jk06NL23DXqsY{9uw%RfC?kwGW!_?AJ_TSe0RmlQ* z`rCC_Cljd2)}}=$iP?==Zmtlx%Y$H|914F6Pu$`0>o<&O6b;c3a^k#VW+60`Hq0&v zr)7Pb`<*_MN~QA&ozxqF@$NC6lW0erCpJ~izbeaVj!gLtW>^g?!U$4OOhuIY+^iPn zME^Pz4Ve87w%-yrH8o!+w;8xGYrM0#9wW0M)(VLExrsw1#-ike@$Z-zh9}NbtKYzl zLCB;oIjqgd17G$7ps=2%M7tA2*^u4wYP_qaa6V06ItiA9$M0|Wp)q(AHX}uY;i_`f zxG3cbauzvMQf%-yD>@m^xFz!h#~#=bd758JpwZdj8`r(&0qq%D)-jc2_6WhxhWXn! zhx9R_-PXo0b*_J=7tfwu#3LcAO>eHW?3Cpvs6X4Q9so8>KZq+^8?;;|zKLrvZuCiE z_?E{UsI2#K&Z!dJ%P4;(4(idmV^@p&aW#>5`}ytwv}2 z?oz#wAHr{o{biY^R5Z@ayY7w~ujzL0C%`!O2xu<`_g&fp!JsgbfP{iFnCQ7))> zb`J{OgbJLO;`*N046l^SHojT@k1~F$fCj=* zqLC%nAC1K|NC1IEH`wbG%7n$faNnkmcnK!(aotP1(;zj2p7-?#&A=4EB%917dw~eh zEMfOZt)$zYGvreH6*@NQlo>=%+V{&gXutKPnN8sR;-;q;A8jACdv^_nJ23{`!c18G zvdvT6gC~r-=Vh|g!fvwBM*QhonoNIk1|H7**~x8==Dq-wBVzyYyfZW@Uihd0%x z+tK#32@*0sAQje_SIThNOtr4Bc4mLPZRU*31NnE8QR^1EjBpu-vldYO=rWrU6>HvP z4e>rb2>8-H3Rs~4D9g~^kebDzHejCWE!|^pOnYaJgFQmro}^c0$f_Bz9bJ z!N7LD7c3aU-tdKQe~NzKIWKiG+C9kmxB|a>)P?YTa0u6Y0+`l`d8@F%NE_J4 zy={FtWw9QbkCvgyQZYveJUQr5k-04=@Ef&|+(+m*;WU7>#p+G{Sz4DAQ#hO7n->X& zzqQDd^&*dd|K?Y?eKOJ;V^Uumt_|B^2o#4Z4A9#rV?LUy$1RuHKEyTrH$0VEtse-g z1sU^K*2`?cAaW|RR9BtFtfoycMD|ufH+(&7Gl&zz1jC`fIoTW7x z#_1w0?vFyYvHB0ZX*KPvy&*nAW0~2l4D#nx$e#Jv=swXV0PwJW7nz3l z$v4)s-DMMVYslE{TDehk)gRGOUT&PFjq^D{{Q1dpj$$zDmlt{R$*?$A-Fz7G8fNP0 zyb_z!;hV3YV5#lXi+%lO=I%O%0!4^1GiWk}%|ICy4@-V=p08xGyG>wO;DpVFf{GW0 zF;{6qkLSatC`O{ozR+MF<)~M!T*u0WK@O*PVa&ALxQ?+~EUJYKtk)4OEb~C}s3c%4 zR5jxtg*ML0XOB*frT6AlRC-B!5qtR?R|W4Cs!2yZ;=@kc(7zc;nbR+1eKa zwR)b%f}mx1gKc)R0Pl?XpC3F0n_9w_C*f&koaPgj$kWG~ElF)}&PXGg3)7OgzY`8> zC`t>mh4~HkMQj{TD|qnO{2?t;&QLyhXj8OB*&B~OP&rFV4p7EmWJSh1j{{LG^WJt; ztc2u#)@$Zuf}fLBnSNngVd4n)oN~YiS?G_zY$XBCrB%>Es#|}T7L#CAlAp};GWz2t zLQcZ(bWROCULTsK@7>v+$awC}m0nZr*j#1#z|zLc2RGxv zrvSub#avFx<-65K!}GMY!;cM;rhXDIDl>ffSKs_|%n(#aVbEIjr%!)UTWC7*;U)Lsv(LuDd`c90`0L+3 zm?b?|&lU>>!X}Uq^3jBB(QXf2t!rb^dNpD9L6Dw-fqFetSpKN10{b4 zV)idBM@SO)l2I@^h{sUmhf3T@J_g(xf7L0~u$WlQNn6{Vg4gjfPLo(MuJo^mrCfuW7A5V1x9SOxXGl zn0h$MkMmQ(@>0c7Q6h9KDP58DzCf$X-xXZN?Lm~yEv}ftI2>yvR^EFlbjb;(94F`l z8ob0=w&6RV@pfwo5%IiDXK2kwPbR($Lc_x1qSd#a>BFRJPr0fN00@*2&EIIkz0+s4 zO0S6YlMs`qogSmF$}yEJ+&71`K=iU}yKq84@Z+bcbvRao(Q;Gk=C_w$aT8U;*Pe#N z<52OEu2kPp0X&jy(tz4qK=%l|oVgtClZbZZG-`^*2$$vK{t!Pf3L3*$zi6uV&=n_X zI^06BhzRJ3IyysWyR?spA~0WnkSC|f_>$a3Pt7=KRYz;ni@2_+er%D7SgS%Qsf2Fmgp)}*XjyNY=yKx%der}o3pLgUxhPzul>NAPg*`?{r7PmS zT!uKK?E{l9&+cJN6LnDiIF5f^WBNfJ~}^6^-aYhe0s!hJT>$cdaBN; z)!tIe44DqZqM8HV-&1pb$E%ncqg2&xLUbp*tt`Fn%+Th{hRqHDU(FTqG9_?C_ZMsm zM$4x{86~5mWfepq?FRcY^J_vDWsGI;Y_L7=>LycQMFtc;s7)ibdt{c%)^nkB^c#M= zOLQ{jH`5B1N(GE}-{(!gE`0xlxj|Rre|XS=vQ&WX22z4yjk>HtoEr0chk0RF)r1y^ zM%;KN)gRIi-yJ9RuM=@Q8B=5BM~hp|#H;`zp;&xF(PWW|`; zA?e=SdK1R$*(I84c8Xxm$M}fB!YG7BM}O;LIpD@gOSADc&huAQc!9~oLZlS^9aj4% ztIfh@z2zCZ!Nu4ugP1)Ia}DLjIOW)BwAJ3eUp&S>z6FHM^^FKB>N#3$+2?>73hR9ki{ zF=lzt3waUSxBd55$CJ*^08(*>WYV*&f00RPz+hN>`V|+NNNPIg^qT2S&PDwl@;Nb# zJaKor)Lh8>gh3eoM)w?+V>h*S$nuVd7?5Uj+;Z$23SGmnxCuLDLV(PCQCs&Obj7r!_^oe<&EC{ z({+1>N!v>l_}~j)^3SAEYI4zHJEwpaOH$MP0`9{l>sX|c_6k+;Bo?gkYa`z)%5-ZJ z7gIvKmf=Sa0G5cDF&^{9@A(R@5lY&l+kvlPxKnunGVND$9~0ZR2RV$676Mmf$u`r= zXv%cA2reP z8)TrF_n#2i{c6u(5XFwqocGxv_$v1p``LSd1IB#)(H77`6ZOlrt%Y$mb=L6L64!F$ zPlv);c%tY1s!RG#>t1neDUINKHf$!gB9lQ4$I0s{m5WMk@z^iPqkmzOBSZeg{+s=; zN?`zUBcnDbJ#dL@@1p!mv2iHwhq%`fWi>k1TaT>*RRD)SB>Uxu&HCf46@%qQ!GwREoD;6RD@!&0wew4 z+E)cs6r~Tn3=bgcq!hi6Cf~ew-}ZY>#Xqo~A?U-3X_DtLA29xWewPF;ELIIo;q2v* zp_1tPEkhzCbin_eH4IIY037zj;{f(k-Ar4ZKz zlG@V@s+rux1H{D|xj11slyh+=>ogq<3$$p=0|;(`fZ#X^%f%nZilEXAUpk$eTuTu0 zm5hPXx;#JOX0oRl`^Gz3#rjhtyWs7#@f03ArB+RzsdxVTTL7EUUP-|!Y7$Xpmp`P8 zvD#kt%Z7DetQ866&NK`v7%j=iuFhId&Q`5iO|_d%BW@hG~q+jHekxIxTeA+XK#dZ&sWJNZwtgyLsyYPm5p%^bTEiAA`CLVnN zvZIkx_nk4ReL*K#%tE|Y0O}n6G~zuVAdX;pcXE(F7{9M17lZPAN7jXh!kd9ewTga& zqV3&ZIxO}p*1;j{vaBa-Z66pR7<@#FQo-m^CmQ_NR#4E%W!}vMq9VnaXVUuKLVN>J zj|C1o>hErY0i1k&vpk7KyMg5cHr1QQU+Gm-usD*~TvZPQ`k@4g@RrWUO2Np*S^g8i zw8yW{82{3mO7_j~cJql?aP$o&k7Y|pVhzvA!wvi|)!rq$nl#nLYYsqlwZ61LRU)*) zztGCz6UkibW_|pCfNe6-Sxlz^smWw6tuR6pGMnbT&oO3JBN_c>%%sMCR(^PWrO2L; zM;0_h3?^P=<0QYd$19i)AD|h?B=qlg(RWd@LcBRt5eU!_y8~X0)``H%^VPM@{3&02 z1e(=>^JC`D{ekh1KN{W9Cvp&a>&AB0#VHvhC`1rs#$joH*m4Eff3NlSKMC@%dS@>R`**7v7M`}Ae*%B?w8lw9K9b{j;07#4;Bf+7bkB8w5F%^8{LW} z2U*M$k%ojlm8RnOZi;YTSsSrpNtM8z=?!lDmX;5?L!jx%M1^t_ZxX()u@9v!4Dr;h zM&j@mO@CzpQ#V}Btle_-7vD%*S}<7m&hIyBo=>5 z8Q@dLr5u#hXAh+>^x|eyZg6exKRl~@bc zuxFKNTV#3}i&oGJFQ2|h2TXLT2^8^;L72_l;tSmNd88M!enGLcOg}ER{Ih zl->u*bheQq{6q5IQOxpUbH!kWj;zg#O-A;=2^_wH$y|C=aO5#_DyLE8M7D^M0p_T@ z9ji>KUy)qw8Ii;+XT09A{$95Yt; z{MiV+Q3fGM)gGnb%RG~x&wm@pJ+x(!ME0S&B~$Dcm(mUx`kt|10~{v=_M*cp8SMwG zO8-%+m*^JO9BUCzES0E@eCfmVGTMca^sD)^x3kJHQUba%Rwju}Z*%EvP~sN`bojUl zmSN1uD4HtL^IqY^KoK{%l4+dTi~$+)`+tP%RQ6~JD1HF7Q7{lTVBqT4`h7`$tPRHc z23p;K@(A(pH8s{nxuoCQK-{j|hVo)uU^^2Z($J*kbiR0Jyc$<=I^Q|oC)#f8f8}KL zSYtlz`}e~^k{3B$PSWk9cZ^vz5M|6kYs!)FkAh0rPcj7Zd#9)QpM^x|rPi>qxe2)} z;_a5Fw)EuGsp%huxNg)s{Bx+qt6SDDi6)biw2oou)y3e+5Ot~Q6FKhv+2+Cpj%k`@ z3#@R+IhdeE)+odktN+>@&W(tdeQ|P5x!`*H!xg`*0FP^Fnb9@W^@x5lHJHONnM3Hv*y`)hx$lfsUp4SafjT9Ah4Nz$xyD?eBK0mWsG^t+hki#tU3LKz&s$DUi+t5h1Z+Dpvq+^BDxep`l zoe-B)Y(3G3^=QRuAw-F+iwoFF3gD;;dadkP!1I;<@I~x!rq+9_{N`8ii@k)WV(`PgH=!v2Cjp^|Vq5IBMOFMmOu9HIe9-m}*|y=W|F z%CtNKnq-V2$&blntwCBe?DTW<)E5=oOW4g2D6v$k>82gnho$IK>N$9J5C1f07w2|d zlpjOkS4;VcyCWYoC)u!ClpkUhf>Q~}zL0oG>PYUZ_8j}_49rGYge6_x3x{?ZjO>D) zIM&bqeiH1ZoGEON8K6$QtTr_Xd^bJQ^|nX4JWgo{1C3d_9pL|IsUG%D@&EY5Es?FB zE|I$dBYS;db;*@ssBeb>Mtv_WY3=fh@CIDaA3w%`RB06sl$mwq=x7ovoa%PzK@^oC zQx4g~U-0(>JqUyL-2M7^AK6KRu}(o+tf@X*&Dige*5K6m(~w&mZ5TwTH{o$q&;%Cv$tu`h-PSi@#kJir6aV$y7F4y7pjv z7{e#euQM`@=YCl&6aKw_wQ=4oYz2P2JT@#<7+o$E^}%+oz?%3KQ+q*W&oNKKhn=t( zw@87~$5w^*@%i)LAgqb)dYa=Cge>No1RH1nE;HNsTHAkDV~R!wq*|_=EZXIXbE~ zy;A$BhD0MhHp z?tg^sK>5Bj6bWa!8c(R`(b>|gVB~)0Y&VL|j;y*CeSsGlu#KvHGZ;OxxU zUV=aSwBWLIJ(uZ5YKi(cQu88=GOwf+YSIc_idOm-_%g=e#}9$OKl-W)uAg6*BY<$; zD9^Va4!L`I5!VV&xy|3?^5VqvfS29KEKyG^Q#-Ro96VF~uJGTYY03ZZd-p7BUb3u) z8LfcC|210tkDmf<6(6<%AHbWo;J{DFgIh*eQ>Y9-o}aBpWQyD=K(QVyv1R$;mN9;={x|E#=y3kP0qU47J0IZb`ki_h}^ z=e7^DC696M?GJA+&REzx@2}v+FqA!67F~33Z9p6G_W-2jkvt(aSbP{65E;Np^#1+@ zK>6?gr|g%$zpYw#NyweWBZ>c@=M&7GnCJH Date: Mon, 14 Oct 2024 11:26:06 +0100 Subject: [PATCH 02/53] updated docs --- pages/stack/protocol/rollup/finality.mdx | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index e8775afed..6aadb668d 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -6,12 +6,6 @@ description: Learn the concept of finality in blockchain systems and the steps i import { Callout } from 'nextra/components' -## Key Concepts - -* Transaction finality: The point at which a transaction is considered irreversible. -* Challenge period: A period during which withdrawals from L2 to L1 can be contested. -* Reorg: A situation where part of the blockchain is replaced, discarding previously confirmed blocks. - # Transaction Finality Transaction finality refers to the point at which a transaction is considered irreversible and is permanently recorded on the blockchain. @@ -26,6 +20,10 @@ Ethereum is designed to provide strong transaction finality guarantees. Here's h This timeframe ensures enough block confirmations to safeguard against reorgs and guarantees secure settlement of transactions. + + Reorg refers to a situation where part of the blockchain is replaced, discarding previously confirmed blocks. + + ## OP Stack Finality OP Stack derive security from Ethereum. Finality occurs when transaction data is posted to Ethereum's data availability (DA) layer, i.e., **Layer 1 (L1)**. From 10bac6569680d63e8107f756dc7b7ef41053d85d Mon Sep 17 00:00:00 2001 From: krofax Date: Mon, 14 Oct 2024 11:46:30 +0100 Subject: [PATCH 03/53] updated the docs and added image --- pages/stack/protocol/rollup/_meta.json | 1 + pages/stack/protocol/rollup/finality.mdx | 21 +++++++++++++-------- 2 files changed, 14 insertions(+), 8 deletions(-) diff --git a/pages/stack/protocol/rollup/_meta.json b/pages/stack/protocol/rollup/_meta.json index bf5f987a5..c2aaa784f 100644 --- a/pages/stack/protocol/rollup/_meta.json +++ b/pages/stack/protocol/rollup/_meta.json @@ -3,5 +3,6 @@ "deposit-flow": "Deposit Flow", "transaction-flow": "Transaction Flow", "withdrawal-flow": "Withdrawal Flow", + "transaction-finality": "Transaction Finality ", "forced-transaction": "Forced Transaction" } \ No newline at end of file diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index 6aadb668d..220dd5b5c 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -4,6 +4,7 @@ lang: en-US description: Learn the concept of finality in blockchain systems and the steps involved in achieving transaction settlement. --- +import Image from 'next/image' import { Callout } from 'nextra/components' # Transaction Finality @@ -37,6 +38,10 @@ In OP Stack, transaction finality involves three main stages: * Finalized: Same as safe, but enough L1 blocks (>65) have passed to ensure the L1 data won't be reorged. This prevents L1 reorgs from affecting the rollup's state and transaction history. + +Transaction Finality Diagram. + + The OP Stack ensures that even if an L2 sequencer produces invalid transactions, the network nodes will reject them, maintaining consensus and security. @@ -76,12 +81,12 @@ A successful challenge (a failed withdrawal claim): * Doesn't cause an L2 reorg. * Only determines the validity of the specific withdrawal claim. - - It's important to understand transaction finality and the challenge period as distinct concepts: +## Conclusion + It's important to understand transaction finality and the challenge period as distinct concepts: + + * The 7-day challenge period verifies the validity of L2 transactions during withdrawals to L1. It does not apply to general L2 transaction finality. + * Users can dispute a withdrawal claim by submitting a fraud proof. This ensures invalid withdrawals are identified before the state is finalized on L1. + * A successful challenge impacts only the withdrawal claim and does not delay L2 transaction finality. + * L2 transaction finality is achieved within minutes after data is posted on L1 and confirmed by approximately `65 blocks (\~10 minutes). + * Even if a challenge is successful, it does not cause a reorg or affect transaction finality on the L2. - * The 7-day challenge period verifies the validity of L2 transactions during withdrawals to L1. It does not apply to general L2 transaction finality. - * Users can dispute a withdrawal claim by submitting a fraud proof. This ensures invalid withdrawals are identified before the state is finalized on L1. - * A successful challenge impacts only the withdrawal claim and does not delay L2 transaction finality. - * L2 transaction finality is achieved within minutes after data is posted on L1 and confirmed by approximately 65 blocks (\~10 minutes). - * Even if a challenge is successful, it does not cause a reorg or affect transaction finality on the L2. - From 2063c26534c0d4e640d16b53be6ae330e619931e Mon Sep 17 00:00:00 2001 From: krofax Date: Mon, 14 Oct 2024 12:06:48 +0100 Subject: [PATCH 04/53] updated the docs --- pages/stack/protocol/rollup/finality.mdx | 62 ++++++++++++------------ 1 file changed, 30 insertions(+), 32 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index 220dd5b5c..01f4b328e 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -1,7 +1,7 @@ --- title: Transaction Finality lang: en-US -description: Learn the concept of finality in blockchain systems and the steps involved in achieving transaction settlement. +description: Learn about finality in blockchain systems and the steps to achieve transaction settlement. --- import Image from 'next/image' @@ -13,80 +13,78 @@ Transaction finality refers to the point at which a transaction is considered ir ## Finality on Ethereum -Ethereum is designed to provide strong transaction finality guarantees. Here's how it works: +Ethereum provides strong guarantees for transaction finality. Here's how it works: -* Time Frame: Under typical network conditions, transactions on Ethereum achieves finality in about 15 minutes. -* Consensus Cycles: This finality period is reached after 2 [epochs](https://info.etherscan.com/epoch-in-ethereum/) -* Block Confirmations: During this time, multiple blocks are added to the chain, each providing additional confirmation of the transactions in previous blocks. - -This timeframe ensures enough block confirmations to safeguard against reorgs and guarantees secure settlement of transactions. +* Time Frame: Under normal network conditions, Ethereum transactions achieve finality in approximately 15 minutes. +* Consensus Cycles: Finality is reached after two [epochs](https://info.etherscan.com/epoch-in-ethereum/). +* Block Confirmations: During this time, multiple blocks are added to the chain, each providing additional confirmation of transactions in earlier blocks. +This timeframe ensures sufficient block confirmations to protect against reorganizations (reorgs) and guarantees secure settlement. - Reorg refers to a situation where part of the blockchain is replaced, discarding previously confirmed blocks. + A reorg occurs when part of the blockchain is replaced, discarding previously confirmed blocks. ## OP Stack Finality -OP Stack derive security from Ethereum. Finality occurs when transaction data is posted to Ethereum's data availability (DA) layer, i.e., **Layer 1 (L1)**. -At this point, the state of the rollup becomes finalized, similar to L1 transaction finality, preventing reorgs at the L2 level. +The OP Stack derives its security from Ethereum. Finality occurs when transaction data is posted to Ethereum's Layer 1 (L1) data availability layer. At this point, the rollup state becomes finalized, similar to L1 finality, preventing L2 reorgs. In OP Stack, transaction finality involves three main stages: -* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data hasn't been posted to L1 yet. It's circulated to the L2 network for speed. +* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to L1. It is circulated within the L2 network for speed. * Safe: The sequencer's batcher posts transaction data to L1. Any L2 node can now derive this transaction. -* Finalized: Same as safe, but enough L1 blocks (>65) have passed to ensure the L1 data won't be reorged. This prevents L1 reorgs from affecting the rollup's state and transaction history. +* Finalized: The state is considered finalized once more than (>65) L1 blocks have passed(approximately 10 minutes), ensuring the L1 data is secure and won't be reorganized. Transaction Finality Diagram. - The OP Stack ensures that even if an L2 sequencer produces invalid transactions, the network nodes will reject them, maintaining consensus and security. + Even if an L2 sequencer generates invalid transactions, OP Stack ensures that network nodes will reject them, maintaining consensus and security. ## The Settlement Layer -This mechanism allows Ethereum to establish a view of the state on an OP Stack chain: +Ethereum provides a view of the state on an OP Stack chain using the following mechanism: * Rollup nodes post data to and monitor Ethereum. -* Ethereum processes transactions based on its consensus rules, without knowledge of the L2. -* For L2 to L1 messages (usually withdrawals), the L2 must prove its state's validity. +* Ethereum processes transactions according to its consensus rules, without requiring knowledge of the L2. +* For L2 to L1 messages (e.g., withdrawals), L2 must prove the validity of its state. To ensure the finality of an OP Stack chain's state, wait for transaction finalization on L1. ## Sequencer Reliability -Sequencers are centralized, raising concerns about potential equivocation (lying about block state). However: +While sequencers are centralized, the risk of equivocation (false reporting of block state) is mitigated as follows: * Sequencers and all L2 nodes must follow consensus rules. * Invalid transactions are rejected by all network nodes. -* This process is similar to how Ethereum and Bitcoin handle transactions. +* This process mirrors how Ethereum and Bitcoin handle transactions. -The L2 state is considered final once a batch is posted to L1 and enough blocks have passed to prevent reorgs. +The L2 state is considered final once the batch is posted to L1 and enough blocks have passed to prevent a reorg. ## Challenge Period -OP Stack rollups use a 7-day withdrawal challenge period for a specific reason: +OP Stack rollups use a 7-day withdrawal challenge period for specific reasons: -* L1 has no inherent knowledge of L2. -* For L2 to L1 withdrawals, L1 needs to verify the withdrawal's validity. +* L1 has no direct knowledge of L2. +* For L2 to L1 withdrawals, L1 must verify the withdrawal's validity. * The 7-day period allows time to dispute withdrawal claims. -* The challenge process uses L2 transaction history to verify claim validity. +* The challenge process uses L2 transaction history to validate withdrawal claims. -A successful challenge (a failed withdrawal claim): +If a challenge is successful, meaning the withdrawal claim fails: -* Doesn't impact the L2 state. -* Doesn't cause an L2 reorg. -* Only determines the validity of the specific withdrawal claim. +* The L2 state remains unaffected. +* There is no L2 reorganization. +* The challenge only affects the specific withdrawal claim. ## Conclusion It's important to understand transaction finality and the challenge period as distinct concepts: - * The 7-day challenge period verifies the validity of L2 transactions during withdrawals to L1. It does not apply to general L2 transaction finality. - * Users can dispute a withdrawal claim by submitting a fraud proof. This ensures invalid withdrawals are identified before the state is finalized on L1. - * A successful challenge impacts only the withdrawal claim and does not delay L2 transaction finality. - * L2 transaction finality is achieved within minutes after data is posted on L1 and confirmed by approximately `65 blocks (\~10 minutes). - * Even if a challenge is successful, it does not cause a reorg or affect transaction finality on the L2. + * The 7-day challenge window ensures the validity of L2 transactions during withdrawals to L1. It is not related to general L2 transaction finality. + * Users can dispute a withdrawal claim by submitting a fraud proof, ensuring invalid withdrawals are caught before finalizing the state on L1. + * A successful challenge impacts only the withdrawal claim and does not affect L2 transaction finality. + * L2 finality occurs within minutes after data is posted to L1 and confirmed by around 65 blocks (\~10 minutes). + * Even if a challenge is successful, it does not cause a reorg or delay L2 transaction finality. From 880a3ebbc59fccbf3ae190cd7dd363103e2695c1 Mon Sep 17 00:00:00 2001 From: krofax Date: Mon, 14 Oct 2024 12:07:24 +0100 Subject: [PATCH 05/53] fix lint issues --- pages/stack/protocol/rollup/finality.mdx | 25 ++++++++++++------------ 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index 01f4b328e..1da3d0248 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -20,9 +20,10 @@ Ethereum provides strong guarantees for transaction finality. Here's how it work * Block Confirmations: During this time, multiple blocks are added to the chain, each providing additional confirmation of transactions in earlier blocks. This timeframe ensures sufficient block confirmations to protect against reorganizations (reorgs) and guarantees secure settlement. + - A reorg occurs when part of the blockchain is replaced, discarding previously confirmed blocks. - + A reorg occurs when part of the blockchain is replaced, discarding previously confirmed blocks. + ## OP Stack Finality @@ -36,13 +37,11 @@ In OP Stack, transaction finality involves three main stages: * Finalized: The state is considered finalized once more than (>65) L1 blocks have passed(approximately 10 minutes), ensuring the L1 data is secure and won't be reorganized. - Transaction Finality Diagram. - - - Even if an L2 sequencer generates invalid transactions, OP Stack ensures that network nodes will reject them, maintaining consensus and security. - + + Even if an L2 sequencer generates invalid transactions, OP Stack ensures that network nodes will reject them, maintaining consensus and security. + ## The Settlement Layer @@ -80,11 +79,11 @@ If a challenge is successful, meaning the withdrawal claim fails: * The challenge only affects the specific withdrawal claim. ## Conclusion - It's important to understand transaction finality and the challenge period as distinct concepts: - * The 7-day challenge window ensures the validity of L2 transactions during withdrawals to L1. It is not related to general L2 transaction finality. - * Users can dispute a withdrawal claim by submitting a fraud proof, ensuring invalid withdrawals are caught before finalizing the state on L1. - * A successful challenge impacts only the withdrawal claim and does not affect L2 transaction finality. - * L2 finality occurs within minutes after data is posted to L1 and confirmed by around 65 blocks (\~10 minutes). - * Even if a challenge is successful, it does not cause a reorg or delay L2 transaction finality. +It's important to understand transaction finality and the challenge period as distinct concepts: +* The 7-day challenge window ensures the validity of L2 transactions during withdrawals to L1. It is not related to general L2 transaction finality. +* Users can dispute a withdrawal claim by submitting a fraud proof, ensuring invalid withdrawals are caught before finalizing the state on L1. +* A successful challenge impacts only the withdrawal claim and does not affect L2 transaction finality. +* L2 finality occurs within minutes after data is posted to L1 and confirmed by around 65 blocks (\~10 minutes). +* Even if a challenge is successful, it does not cause a reorg or delay L2 transaction finality. From 7cbd7152cf74c8773bcc83835ca1b7509b12d355 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:13:46 +0100 Subject: [PATCH 06/53] updated finality docs --- pages/stack/protocol/rollup/finality.mdx | 144 +++++++++++++++-------- 1 file changed, 95 insertions(+), 49 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index 1da3d0248..528581f33 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -1,89 +1,135 @@ --- -title: Transaction Finality +title: Transaction Finality lang: en-US -description: Learn about finality in blockchain systems and the steps to achieve transaction settlement. +description: Learn about finality in OP Stack and the steps to achieve transaction settlement. --- import Image from 'next/image' import { Callout } from 'nextra/components' -# Transaction Finality +# OP Stack rollups -Transaction finality refers to the point at which a transaction is considered irreversible and is permanently recorded on the blockchain. +OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum’s consensus. This way, OP Stack rollup can take advantage of Ethereum’s ordering mechanism and finalize its own blocks without needing to create a new consensus layer. -## Finality on Ethereum +## State Machines and Transaction Processing -Ethereum provides strong guarantees for transaction finality. Here's how it works: +State machines, such as the EVM, rely on input lists (transactions) to evolve from one state to another. The list and its order are vital because incorrect ordering can lead to an invalid state. -* Time Frame: Under normal network conditions, Ethereum transactions achieve finality in approximately 15 minutes. -* Consensus Cycles: Finality is reached after two [epochs](https://info.etherscan.com/epoch-in-ethereum/). -* Block Confirmations: During this time, multiple blocks are added to the chain, each providing additional confirmation of transactions in earlier blocks. +For example, if a user tries to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making ordering an essential aspect of consensus. -This timeframe ensures sufficient block confirmations to protect against reorganizations (reorgs) and guarantees secure settlement. +## Commutative vs non-Commutative operations - - A reorg occurs when part of the blockchain is replaced, discarding previously confirmed blocks. - +Commutative operations allow input order to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Hence, the list's availability and ordering are fundamental to ensuring the integrity of the system. -## OP Stack Finality +## Consensus and Ordering -The OP Stack derives its security from Ethereum. Finality occurs when transaction data is posted to Ethereum's Layer 1 (L1) data availability layer. At this point, the rollup state becomes finalized, similar to L1 finality, preventing L2 reorgs. +Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum’s consensus (via Proof of Stake) is used to achieve transaction ordering and finality. + +## Why piggybacking on Ethereum? + +By publishing rollup blocks on Ethereum, OP Stack effectively outsource it's consensus mechanism. Instead of running a separate consensus protocol, they rely on Ethereum's ordering and finality guarantees. + +Key benefits of this approach include: + +* OP Stack inherit Ethereum’s security and ordering properties. +* The OP Stack simplifies the design and development process by removing the need for a separate consensus protocol. +* Attack vectors such as double-spends are mitigated by Ethereum’s inherent mechanisms. + +### Transaction finality states In OP Stack, transaction finality involves three main stages: -* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to L1. It is circulated within the L2 network for speed. +* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data will not been posted to L1. It is circulated within the L2 network for speed. * Safe: The sequencer's batcher posts transaction data to L1. Any L2 node can now derive this transaction. -* Finalized: The state is considered finalized once more than (>65) L1 blocks have passed(approximately 10 minutes), ensuring the L1 data is secure and won't be reorganized. +* Finalized: Transactions is finalized once more than (>65) L1 blocks have passed(approximately 20 minutes), ensuring the L1 data is secure and won't be reorganized. Transaction Finality Diagram. - - Even if an L2 sequencer generates invalid transactions, OP Stack ensures that network nodes will reject them, maintaining consensus and security. - +## Sequencer Operations -## The Settlement Layer +The sequencer (block producer) handles transaction processing through the following steps: -Ethereum provides a view of the state on an OP Stack chain using the following mechanism: +1. **Pre-publishing Distribution:** + - Sequencer receives transactions from users + - Creates blocks containing these transactions + - Distributes blocks to network nodes before L1 publication + - Nodes mark these blocks as "unsafe" -* Rollup nodes post data to and monitor Ethereum. -* Ethereum processes transactions according to its consensus rules, without requiring knowledge of the L2. -* For L2 to L1 messages (e.g., withdrawals), L2 must prove the validity of its state. +2. **L1 Publication:** + - Sequencer publishes blocks to Ethereum + - Blocks become "safe" once included in L1 + - Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes) -To ensure the finality of an OP Stack chain's state, wait for transaction finalization on L1. +### Sequencer Trust -## Sequencer Reliability +The sequencer's role involves certain trust assumptions: -While sequencers are centralized, the risk of equivocation (false reporting of block state) is mitigated as follows: +- Can temporarily withhold transactions. +- May attempt to reorder transactions before L1 publication. +- Cannot modify or censor transactions once published to L1. +- Cannot affect finalized transactions. -* Sequencers and all L2 nodes must follow consensus rules. -* Invalid transactions are rejected by all network nodes. -* This process mirrors how Ethereum and Bitcoin handle transactions. +## Block and transaction validity in the OP Stack -The L2 state is considered final once the batch is posted to L1 and enough blocks have passed to prevent a reorg. +When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated; otherwise, it is discarded. Nodes execute valid blocks and update the rollup state accordingly. -## Challenge Period +### Reorgs and finality -OP Stack rollups use a 7-day withdrawal challenge period for specific reasons: +A block's inclusion in a finalized Ethereum block ensures its finality. If a rollup block is included in a finalized Ethereum block, it cannot be reorged. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is handled by the **OP Stack** architecture. -* L1 has no direct knowledge of L2. -* For L2 to L1 withdrawals, L1 must verify the withdrawal's validity. -* The 7-day period allows time to dispute withdrawal claims. -* The challenge process uses L2 transaction history to validate withdrawal claims. +### Reorg Handling -If a challenge is successful, meaning the withdrawal claim fails: +When L1 reorgs occur: -* The L2 state remains unaffected. -* There is no L2 reorganization. -* The challenge only affects the specific withdrawal claim. +1. Nodes detect the L1 reorg +2. Affected L2 blocks return to "unsafe" status +3. Sequencer typically republishes the same transactions +4. System returns to consistent state after reprocessing -## Conclusion +## The role of the proof system + +The proof system, is entirely separate from the core OP Stack protocol. It is an app-level validation system designed to ensure that certain claims about the rollup's state are correct. + +### What is a claim? + +A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `XYZ`. Other participants can challenge this claim if they believe it to be incorrect. + +### Fault proofs and challenges + +Challenges revolve around proving whether a given claim is valid. However, the outcome of a challenge does not affect the underlying chain. For example, if a claim about the state of the rollup at a certain block is proven wrong, it only affects the app-level functionality, not the OP Stack protocol. + +### Bridge Independence -It's important to understand transaction finality and the challenge period as distinct concepts: +Important points about bridge systems: + +- Bridges are application-level constructs +- They operate independently of the core rollup protocol +- Bridge security doesn't affect L2 transaction validity +- Bridge failures don't cause L2 reorgs or state changes + +### Example: Custom bridges in OP Stack + +A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is app-level and not native to the OP Stack rollup. If there’s an issue with the bridge, such as incorrect proof validation, it doesn’t affect the rollup itself but impacts the subjective value of the bridged assets. + +## 7 days challenge period in OP Stack + +The 7 days challenge period exists to give time for challenges to be raised and resolved. While the rollup chain itself finalizes quickly (within 20 minutes), withdrawals from Layer 2 are delayed to allow for fault-proof validation. This ensures that malicious activity can be detected and challenged before it affects the system. + +### Why 7 days? + +The 7 day period is a reasonable time frame to allow participants to organize a response, potentially even organizing a hard fork on Layer 1 to address severe issues. In the context of the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup designs that may be built on top of the core protocol. + +### Withdrawal Delays vs. Finality + +One common misconception is confusing withdrawal delays with transaction finality: + +- Transaction finality occurs in approximately 20 minutes +- Withdrawal delays (often 7 days) are separate from transaction finality +- Withdrawal delays are application-level security features +- These delays affect only L1 withdrawals, not L2 transaction finality + +## Conclusion -* The 7-day challenge window ensures the validity of L2 transactions during withdrawals to L1. It is not related to general L2 transaction finality. -* Users can dispute a withdrawal claim by submitting a fraud proof, ensuring invalid withdrawals are caught before finalizing the state on L1. -* A successful challenge impacts only the withdrawal claim and does not affect L2 transaction finality. -* L2 finality occurs within minutes after data is posted to L1 and confirmed by around 65 blocks (\~10 minutes). -* Even if a challenge is successful, it does not cause a reorg or delay L2 transaction finality. +Transaction finality on the OP Stack depends heavily on Ethereum’s consensus mechanism. The OP Stack ensures that rollups inherit Ethereum’s finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. From f35ba6c66e8f29f153ab295867c785a3266976c6 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:15:23 +0100 Subject: [PATCH 07/53] fix linting errors --- pages/stack/protocol/rollup/finality.mdx | 62 ++++++++++++------------ words.txt | 1 - 2 files changed, 31 insertions(+), 32 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index 528581f33..4f4a4ebf1 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -9,7 +9,7 @@ import { Callout } from 'nextra/components' # OP Stack rollups -OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum’s consensus. This way, OP Stack rollup can take advantage of Ethereum’s ordering mechanism and finalize its own blocks without needing to create a new consensus layer. +OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum's consensus. This way, OP Stack rollup can take advantage of Ethereum's ordering mechanism and finalize its own blocks without needing to create a new consensus layer. ## State Machines and Transaction Processing @@ -23,7 +23,7 @@ Commutative operations allow input order to change without affecting the outcome ## Consensus and Ordering -Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum’s consensus (via Proof of Stake) is used to achieve transaction ordering and finality. +Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum's consensus (via Proof of Stake) is used to achieve transaction ordering and finality. ## Why piggybacking on Ethereum? @@ -31,9 +31,9 @@ By publishing rollup blocks on Ethereum, OP Stack effectively outsource it's con Key benefits of this approach include: -* OP Stack inherit Ethereum’s security and ordering properties. +* OP Stack inherit Ethereum's security and ordering properties. * The OP Stack simplifies the design and development process by removing the need for a separate consensus protocol. -* Attack vectors such as double-spends are mitigated by Ethereum’s inherent mechanisms. +* Attack vectors such as double-spends are mitigated by Ethereum's inherent mechanisms. ### Transaction finality states @@ -51,25 +51,25 @@ In OP Stack, transaction finality involves three main stages: The sequencer (block producer) handles transaction processing through the following steps: -1. **Pre-publishing Distribution:** - - Sequencer receives transactions from users - - Creates blocks containing these transactions - - Distributes blocks to network nodes before L1 publication - - Nodes mark these blocks as "unsafe" +1. Pre-publishing Distribution: + * Sequencer receives transactions from users + * Creates blocks containing these transactions + * Distributes blocks to network nodes before L1 publication + * Nodes mark these blocks as "unsafe" -2. **L1 Publication:** - - Sequencer publishes blocks to Ethereum - - Blocks become "safe" once included in L1 - - Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes) +2. L1 Publication: + * Sequencer publishes blocks to Ethereum + * Blocks become "safe" once included in L1 + * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes) ### Sequencer Trust The sequencer's role involves certain trust assumptions: -- Can temporarily withhold transactions. -- May attempt to reorder transactions before L1 publication. -- Cannot modify or censor transactions once published to L1. -- Cannot affect finalized transactions. +* Can temporarily withhold transactions. +* May attempt to reorder transactions before L1 publication. +* Cannot modify or censor transactions once published to L1. +* Cannot affect finalized transactions. ## Block and transaction validity in the OP Stack @@ -83,10 +83,10 @@ A block's inclusion in a finalized Ethereum block ensures its finality. If a rol When L1 reorgs occur: -1. Nodes detect the L1 reorg -2. Affected L2 blocks return to "unsafe" status -3. Sequencer typically republishes the same transactions -4. System returns to consistent state after reprocessing +1. Nodes detect the L1 reorg +2. Affected L2 blocks return to "unsafe" status +3. Sequencer typically republishes the same transactions +4. System returns to consistent state after reprocessing ## The role of the proof system @@ -104,14 +104,14 @@ Challenges revolve around proving whether a given claim is valid. However, the o Important points about bridge systems: -- Bridges are application-level constructs -- They operate independently of the core rollup protocol -- Bridge security doesn't affect L2 transaction validity -- Bridge failures don't cause L2 reorgs or state changes +* Bridges are application-level constructs +* They operate independently of the core rollup protocol +* Bridge security doesn't affect L2 transaction validity +* Bridge failures don't cause L2 reorgs or state changes ### Example: Custom bridges in OP Stack -A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is app-level and not native to the OP Stack rollup. If there’s an issue with the bridge, such as incorrect proof validation, it doesn’t affect the rollup itself but impacts the subjective value of the bridged assets. +A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is app-level and not native to the OP Stack rollup. If there's an issue with the bridge, such as incorrect proof validation, it doesn't affect the rollup itself but impacts the subjective value of the bridged assets. ## 7 days challenge period in OP Stack @@ -125,11 +125,11 @@ The 7 day period is a reasonable time frame to allow participants to organize a One common misconception is confusing withdrawal delays with transaction finality: -- Transaction finality occurs in approximately 20 minutes -- Withdrawal delays (often 7 days) are separate from transaction finality -- Withdrawal delays are application-level security features -- These delays affect only L1 withdrawals, not L2 transaction finality +* Transaction finality occurs in approximately 20 minutes +* Withdrawal delays (often 7 days) are separate from transaction finality +* Withdrawal delays are application-level security features +* These delays affect only L1 withdrawals, not L2 transaction finality ## Conclusion -Transaction finality on the OP Stack depends heavily on Ethereum’s consensus mechanism. The OP Stack ensures that rollups inherit Ethereum’s finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. +Transaction finality on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. diff --git a/words.txt b/words.txt index 51f3a1857..33bb71948 100644 --- a/words.txt +++ b/words.txt @@ -355,7 +355,6 @@ therealbytes Thirdweb threadcreate tility -timeframe timeseries Tranfer trustlessly From e87c41b46c1f110a000a43593065f5141e72bc6f Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:27:04 +0100 Subject: [PATCH 08/53] updated few grammar errors --- pages/stack/protocol/rollup/finality.mdx | 138 +++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 pages/stack/protocol/rollup/finality.mdx diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx new file mode 100644 index 000000000..b4ef46306 --- /dev/null +++ b/pages/stack/protocol/rollup/finality.mdx @@ -0,0 +1,138 @@ +--- +title: Transaction Finality +lang: en-US +description: Learn about finality in OP Stack and the steps to achieve transaction settlement. +--- + +import Image from 'next/image' +import { Callout } from 'nextra/components' + +# OP Stack rollups + +OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum's consensus. This way, OP Stack rollup can take advantage of Ethereum's ordering mechanism and finalize its own blocks without needing to create a new consensus layer. + +## State Machines and Transaction Processing + +State machines, such as the EVM, rely on input lists (transactions) to evolve from one state to another. The list and its order are vital because incorrect ordering can lead to an invalid state. + +For example, if a user tries to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making ordering an essential aspect of consensus. + +## Commutative vs non-Commutative operations + +Commutative operations allow input order to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Hence, the list's availability and ordering are fundamental to ensuring the integrity of the system. + +## Consensus and Ordering + +Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum's consensus (via Proof of Stake) is used to achieve transaction ordering and finality. + +## Why piggybacking on Ethereum? + +By publishing rollup blocks on Ethereum, OP Stack effectively outsource it's consensus mechanism. Instead of running a separate consensus protocol, they rely on Ethereum's ordering and finality guarantees. + +Key benefits of this approach include: + +* OP Stack inherits Ethereum's security and ordering properties. +* The OP Stack simplifies the design and development process by removing the need for a separate consensus protocol. +* Attack vectors such as double-spends are mitigated by Ethereum's inherent mechanisms. + +### Transaction finality states + +In OP Stack, transaction finality involves three main stages: + +* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data has not been posted to L1. It is circulated within the L2 network for speed. + +* Safe: The sequencer's batcher has posted transaction data to L1. Any L2 node can now derive this transaction. + +* Finalized: Transactions are finalized once more than 65 L1 blocks have passed (approximately 20 minutes), ensuring the L1 data is secure and won't be reorganized. + +Transaction Finality Diagram. + +## Sequencer Operations + +The sequencer (block producer) handles transaction processing through the following steps: + +1. Pre-publishing Distribution: + * Sequencer receives transactions from users + * Creates blocks containing these transactions + * Distributes blocks to network nodes before L1 publication + * Nodes mark these blocks as "unsafe" + +2. L1 Publication: + * Sequencer publishes blocks to Ethereum + * Blocks become "safe" once included in L1 + * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes) + +### Sequencer Trust + +The sequencer's role involves certain trust assumptions: + +* Can temporarily withhold transactions. +* May attempt to reorder transactions before L1 publication. +* Cannot modify or censor transactions once published to L1. +* Cannot affect finalized transactions. + +## Block and transaction validity in the OP Stack + +When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated; otherwise, it is discarded. Nodes execute valid blocks and update the rollup state accordingly. + +### Reorgs and finality + +A block's inclusion in a finalized Ethereum block ensures its finality. If a rollup block is included in a finalized Ethereum block, it cannot be reorged. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is handled by the **OP Stack** architecture. + +### Reorg Handling + +When L1 reorgs occur: + +1. Nodes detect the L1 reorg +2. Affected L2 blocks return to "unsafe" status +3. Sequencer typically republishes the same transactions +4. System returns to a consistent state after reprocessing + +## The role of the proof system + +The proof system, is entirely separate from the core OP Stack protocol. It is an app-level validation system designed to ensure that certain claims about the rollup's state are correct. + +### What is a claim? + +A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `XYZ`. Other participants can challenge this claim if they believe it to be incorrect. + +### Fault proofs and challenges + +Challenges revolve around proving whether a given claim is valid. However, the outcome of a challenge does not affect the underlying chain. For example, if a claim about the state of the rollup at a certain block is proven wrong, it only affects the app-level functionality, not the OP Stack protocol. + +### Bridge Independence + +Important points about bridge systems: + +* Bridges are application-level constructs +* They operate independently of the core rollup protocol +* Bridge security doesn't affect L2 transaction validity +* Bridge failures don't cause L2 reorgs or state changes + +### Example: Custom bridges in OP Stack + +A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. +However, this bridge is app-level and not native to the OP Stack rollup. If there's an issue with the bridge, such as incorrect proof validation, it doesn't affect the rollup itself but impacts the subjective value of the bridged assets. + +## 7-Day Challenge Period in OP Stack + +The 7-day challenge period exists to give time for challenges to be raised and resolved. +While the rollup chain itself finalizes quickly (within 20 minutes), withdrawals from Layer 2 are delayed to allow for fault-proof validation. +This ensures that malicious activity can be detected and challenged before it affects the system. + +### Why 7 days? + +The 7 day period is a reasonable time frame to allow participants to organize a response, potentially even organizing a hard fork on Layer 1 to address severe issues. In the context of the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup designs that may be built on top of the core protocol. + +### Withdrawal Delays vs. Finality + +One common misconception is confusing withdrawal delays with transaction finality: + +* Transaction finality occurs in approximately 20 minutes +* Withdrawal delays (often 7 days) are separate from transaction finality +* Withdrawal delays are application-level security features +* These delays affect only L1 withdrawals, not L2 transaction finality + +## Conclusion + +Transaction finality on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. From d1003e68e0657889a0e5c08874f5418d18ff4526 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:30:04 +0100 Subject: [PATCH 09/53] updated the tones --- pages/stack/protocol/rollup/finality.mdx | 135 +++++++++++------------ words.txt | 5 +- 2 files changed, 69 insertions(+), 71 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index b4ef46306..6cc087542 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -7,132 +7,131 @@ description: Learn about finality in OP Stack and the steps to achieve transacti import Image from 'next/image' import { Callout } from 'nextra/components' -# OP Stack rollups +# OP Stack Rollups -OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum's consensus. This way, OP Stack rollup can take advantage of Ethereum's ordering mechanism and finalize its own blocks without needing to create a new consensus layer. +The **OP Stack** rollup is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack rollup leverages Ethereum's consensus. This enables the rollup to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. ## State Machines and Transaction Processing -State machines, such as the EVM, rely on input lists (transactions) to evolve from one state to another. The list and its order are vital because incorrect ordering can lead to an invalid state. +State machines, such as the Ethereum Virtual Machine (EVM), rely on input lists (transactions) to evolve from one state to another. The order of the transactions is critical because incorrect ordering can lead to an invalid state. -For example, if a user tries to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making ordering an essential aspect of consensus. +For example, if a user attempts to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making transaction ordering an essential aspect of consensus. -## Commutative vs non-Commutative operations +## Commutative vs. Non-Commutative Operations -Commutative operations allow input order to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Hence, the list's availability and ordering are fundamental to ensuring the integrity of the system. +Commutative operations allow the order of inputs to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Therefore, both the availability and the order of the transaction list are fundamental to ensuring the system's integrity. ## Consensus and Ordering -Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum's consensus (via Proof of Stake) is used to achieve transaction ordering and finality. +Consensus determines the valid chain or list of transactions. In the OP Stack, Ethereum's Proof of Stake (PoS) consensus mechanism is used to achieve transaction ordering and finality. -## Why piggybacking on Ethereum? +## Why Use Ethereum's Consensus? -By publishing rollup blocks on Ethereum, OP Stack effectively outsource it's consensus mechanism. Instead of running a separate consensus protocol, they rely on Ethereum's ordering and finality guarantees. +By publishing rollup blocks on Ethereum, the OP Stack effectively outsources its consensus mechanism. Instead of creating a separate consensus protocol, the OP Stack relies on Ethereum's ordering and finality guarantees. -Key benefits of this approach include: +### Key benefits of this approach: -* OP Stack inherits Ethereum's security and ordering properties. -* The OP Stack simplifies the design and development process by removing the need for a separate consensus protocol. -* Attack vectors such as double-spends are mitigated by Ethereum's inherent mechanisms. +* OP Stack inherits Ethereum's security and transaction ordering properties. +* It simplifies the design and development process by eliminating the need for a separate consensus protocol. +* Attack vectors, such as double-spends, are mitigated by Ethereum's security mechanisms. -### Transaction finality states +## Transaction Finality States -In OP Stack, transaction finality involves three main stages: +In the OP Stack, transaction finality progresses through three key stages: -* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data has not been posted to L1. It is circulated within the L2 network for speed. +1. **Unsafe:** The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. -* Safe: The sequencer's batcher has posted transaction data to L1. Any L2 node can now derive this transaction. +2. **Safe:** The sequencer's batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. -* Finalized: Transactions are finalized once more than 65 L1 blocks have passed (approximately 20 minutes), ensuring the L1 data is secure and won't be reorganized. +3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 20 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. Transaction Finality Diagram. ## Sequencer Operations -The sequencer (block producer) handles transaction processing through the following steps: +The **sequencer** (block producer) processes transactions in the following steps: -1. Pre-publishing Distribution: - * Sequencer receives transactions from users - * Creates blocks containing these transactions - * Distributes blocks to network nodes before L1 publication - * Nodes mark these blocks as "unsafe" +1. **Pre-publishing Distribution:** + * The sequencer receives transactions from users. + * It creates blocks containing these transactions. + * It distributes these blocks to network nodes before L1 publication. + * Nodes mark these blocks as "unsafe." -2. L1 Publication: - * Sequencer publishes blocks to Ethereum - * Blocks become "safe" once included in L1 - * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes) +2. **L1 Publication:** + * The sequencer publishes the blocks to Ethereum (L1). + * Once included in L1, the blocks are marked as "safe." + * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes). -### Sequencer Trust +### Sequencer Trust Assumptions -The sequencer's role involves certain trust assumptions: +The sequencer operates with the following trust assumptions: -* Can temporarily withhold transactions. -* May attempt to reorder transactions before L1 publication. -* Cannot modify or censor transactions once published to L1. -* Cannot affect finalized transactions. +* It can temporarily withhold transactions. +* It may attempt to reorder transactions before L1 publication. +* Once transactions are published on L1, the sequencer cannot modify or censor them. +* The sequencer cannot affect finalized transactions. -## Block and transaction validity in the OP Stack +## Block and Transaction Validity in the OP Stack -When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated; otherwise, it is discarded. Nodes execute valid blocks and update the rollup state accordingly. +When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the rollup state as required. -### Reorgs and finality +### Reorgs and Finality -A block's inclusion in a finalized Ethereum block ensures its finality. If a rollup block is included in a finalized Ethereum block, it cannot be reorged. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is handled by the **OP Stack** architecture. +Once a rollup block is included in a finalized Ethereum block, it cannot be reorganized. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is managed by the OP Stack architecture. -### Reorg Handling +### Handling Reorgs -When L1 reorgs occur: +If an Ethereum reorganization (reorg) occurs: -1. Nodes detect the L1 reorg -2. Affected L2 blocks return to "unsafe" status -3. Sequencer typically republishes the same transactions -4. System returns to a consistent state after reprocessing +1. L2 nodes detect the L1 reorg. +2. Affected L2 blocks revert to an "unsafe" status. +3. The sequencer typically republishes the same transactions. +4. The system returns to a consistent state after reprocessing. -## The role of the proof system +## The Role of the Proof System -The proof system, is entirely separate from the core OP Stack protocol. It is an app-level validation system designed to ensure that certain claims about the rollup's state are correct. +The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the rollup's state. -### What is a claim? +### What Is a Claim? -A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `XYZ`. Other participants can challenge this claim if they believe it to be incorrect. +A claim in the context of OP Stack rollups is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. -### Fault proofs and challenges +### Fault Proofs and Challenges -Challenges revolve around proving whether a given claim is valid. However, the outcome of a challenge does not affect the underlying chain. For example, if a claim about the state of the rollup at a certain block is proven wrong, it only affects the app-level functionality, not the OP Stack protocol. +Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the rollup's state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. ### Bridge Independence -Important points about bridge systems: +Key aspects of bridge systems include: -* Bridges are application-level constructs -* They operate independently of the core rollup protocol -* Bridge security doesn't affect L2 transaction validity -* Bridge failures don't cause L2 reorgs or state changes +* Bridges are application-level constructs. +* They operate independently from the core rollup protocol. +* Bridge security does not affect the validity of L2 transactions. +* Bridge failures do not cause L2 reorgs or state changes. -### Example: Custom bridges in OP Stack +### Example: Custom Bridges in OP Stack -A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. -However, this bridge is app-level and not native to the OP Stack rollup. If there's an issue with the bridge, such as incorrect proof validation, it doesn't affect the rollup itself but impacts the subjective value of the bridged assets. +A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack rollup. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the rollup itself but affects the subjective value of the bridged assets. ## 7-Day Challenge Period in OP Stack -The 7-day challenge period exists to give time for challenges to be raised and resolved. -While the rollup chain itself finalizes quickly (within 20 minutes), withdrawals from Layer 2 are delayed to allow for fault-proof validation. -This ensures that malicious activity can be detected and challenged before it affects the system. +The 7-day challenge period provides time for challenges to be raised and resolved. +Although the rollup chain finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. +This delay ensures that any malicious activity can be detected and addressed before it impacts the system. -### Why 7 days? +### Why Seven Days? -The 7 day period is a reasonable time frame to allow participants to organize a response, potentially even organizing a hard fork on Layer 1 to address severe issues. In the context of the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup designs that may be built on top of the core protocol. +The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup designs that may be built on top of the core protocol. ### Withdrawal Delays vs. Finality One common misconception is confusing withdrawal delays with transaction finality: -* Transaction finality occurs in approximately 20 minutes -* Withdrawal delays (often 7 days) are separate from transaction finality -* Withdrawal delays are application-level security features -* These delays affect only L1 withdrawals, not L2 transaction finality +* Transaction finality occurs in approximately 20 minutes. +* Withdrawal delays (often 7 days) are separate from transaction finality. +* Withdrawal delays are application-level security features. +* These delays affect only L1 withdrawals, not L2 transaction finality. ## Conclusion -Transaction finality on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. +Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While rollup blocks finalize quickly, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. diff --git a/words.txt b/words.txt index 93c865012..b86d09017 100644 --- a/words.txt +++ b/words.txt @@ -16,6 +16,7 @@ Arweave authrpc Badgeholder's Badgeholders +badgeholders basefee BGEZ BGTZ @@ -169,7 +170,6 @@ leveldb lightkdf logfile logfmt -marketshare MAXAGE maxage MAXBACKUPS @@ -204,7 +204,6 @@ MTHI MTLO MULT multiaddr -Multichain multichain multiclient multisigs @@ -303,7 +302,7 @@ replayability reproven REQUIREDBLOCKS requiredblocks -Rollouts +rollouts Rollups rollups Routescan From 5d503820b49f59bf718df498afc619291236d07d Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:36:28 +0100 Subject: [PATCH 10/53] updated some concepts --- pages/stack/protocol/rollup/finality.mdx | 27 ++++++++++++------------ 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/protocol/rollup/finality.mdx index 6cc087542..fbbe50540 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/protocol/rollup/finality.mdx @@ -7,9 +7,10 @@ description: Learn about finality in OP Stack and the steps to achieve transacti import Image from 'next/image' import { Callout } from 'nextra/components' -# OP Stack Rollups +# The OP Stack consensus mechanism -The **OP Stack** rollup is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack rollup leverages Ethereum's consensus. This enables the rollup to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. +The OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. +This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. ## State Machines and Transaction Processing @@ -27,7 +28,7 @@ Consensus determines the valid chain or list of transactions. In the OP Stack, E ## Why Use Ethereum's Consensus? -By publishing rollup blocks on Ethereum, the OP Stack effectively outsources its consensus mechanism. Instead of creating a separate consensus protocol, the OP Stack relies on Ethereum's ordering and finality guarantees. +By publishing blocks on Ethereum, the OP Stack effectively outsources its consensus mechanism. Instead of creating a separate consensus protocol, the OP Stack relies on Ethereum's ordering and finality guarantees. ### Key benefits of this approach: @@ -73,11 +74,11 @@ The sequencer operates with the following trust assumptions: ## Block and Transaction Validity in the OP Stack -When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the rollup state as required. +When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the state as required. ### Reorgs and Finality -Once a rollup block is included in a finalized Ethereum block, it cannot be reorganized. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is managed by the OP Stack architecture. +Once a block is included in a finalized Ethereum block, it cannot be reorganized. Therefore, blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is managed by the OP Stack architecture. ### Handling Reorgs @@ -90,38 +91,38 @@ If an Ethereum reorganization (reorg) occurs: ## The Role of the Proof System -The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the rollup's state. +The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the transaction state. ### What Is a Claim? -A claim in the context of OP Stack rollups is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. +A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. ### Fault Proofs and Challenges -Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the rollup's state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. +Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. ### Bridge Independence Key aspects of bridge systems include: * Bridges are application-level constructs. -* They operate independently from the core rollup protocol. +* They operate independently from the core OP Stack protocol. * Bridge security does not affect the validity of L2 transactions. * Bridge failures do not cause L2 reorgs or state changes. ### Example: Custom Bridges in OP Stack -A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack rollup. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the rollup itself but affects the subjective value of the bridged assets. +A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. ## 7-Day Challenge Period in OP Stack The 7-day challenge period provides time for challenges to be raised and resolved. -Although the rollup chain finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. +Although OP Stack finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. This delay ensures that any malicious activity can be detected and addressed before it impacts the system. ### Why Seven Days? -The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup designs that may be built on top of the core protocol. +The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. ### Withdrawal Delays vs. Finality @@ -134,4 +135,4 @@ One common misconception is confusing withdrawal delays with transaction finalit ## Conclusion -Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While rollup blocks finalize quickly, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. +Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While blocks finalize quickly, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. From 96d6722ee2dcdd423379ee69fb9f603607e43210 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:49:16 +0100 Subject: [PATCH 11/53] removed duplications --- pages/stack/protocol/rollup/_meta.json | 8 -- pages/stack/transactions/finality.mdx | 135 ------------------ .../transaction-finality.mdx} | 36 ++--- 3 files changed, 19 insertions(+), 160 deletions(-) delete mode 100644 pages/stack/protocol/rollup/_meta.json delete mode 100644 pages/stack/transactions/finality.mdx rename pages/stack/{protocol/rollup/finality.mdx => transactions/transaction-finality.mdx} (94%) diff --git a/pages/stack/protocol/rollup/_meta.json b/pages/stack/protocol/rollup/_meta.json deleted file mode 100644 index c2aaa784f..000000000 --- a/pages/stack/protocol/rollup/_meta.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "overview": "Rollup Overview", - "deposit-flow": "Deposit Flow", - "transaction-flow": "Transaction Flow", - "withdrawal-flow": "Withdrawal Flow", - "transaction-finality": "Transaction Finality ", - "forced-transaction": "Forced Transaction" -} \ No newline at end of file diff --git a/pages/stack/transactions/finality.mdx b/pages/stack/transactions/finality.mdx deleted file mode 100644 index 4f4a4ebf1..000000000 --- a/pages/stack/transactions/finality.mdx +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Transaction Finality -lang: en-US -description: Learn about finality in OP Stack and the steps to achieve transaction settlement. ---- - -import Image from 'next/image' -import { Callout } from 'nextra/components' - -# OP Stack rollups - -OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum's consensus. This way, OP Stack rollup can take advantage of Ethereum's ordering mechanism and finalize its own blocks without needing to create a new consensus layer. - -## State Machines and Transaction Processing - -State machines, such as the EVM, rely on input lists (transactions) to evolve from one state to another. The list and its order are vital because incorrect ordering can lead to an invalid state. - -For example, if a user tries to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making ordering an essential aspect of consensus. - -## Commutative vs non-Commutative operations - -Commutative operations allow input order to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Hence, the list's availability and ordering are fundamental to ensuring the integrity of the system. - -## Consensus and Ordering - -Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum's consensus (via Proof of Stake) is used to achieve transaction ordering and finality. - -## Why piggybacking on Ethereum? - -By publishing rollup blocks on Ethereum, OP Stack effectively outsource it's consensus mechanism. Instead of running a separate consensus protocol, they rely on Ethereum's ordering and finality guarantees. - -Key benefits of this approach include: - -* OP Stack inherit Ethereum's security and ordering properties. -* The OP Stack simplifies the design and development process by removing the need for a separate consensus protocol. -* Attack vectors such as double-spends are mitigated by Ethereum's inherent mechanisms. - -### Transaction finality states - -In OP Stack, transaction finality involves three main stages: - -* Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data will not been posted to L1. It is circulated within the L2 network for speed. - -* Safe: The sequencer's batcher posts transaction data to L1. Any L2 node can now derive this transaction. - -* Finalized: Transactions is finalized once more than (>65) L1 blocks have passed(approximately 20 minutes), ensuring the L1 data is secure and won't be reorganized. - -Transaction Finality Diagram. - -## Sequencer Operations - -The sequencer (block producer) handles transaction processing through the following steps: - -1. Pre-publishing Distribution: - * Sequencer receives transactions from users - * Creates blocks containing these transactions - * Distributes blocks to network nodes before L1 publication - * Nodes mark these blocks as "unsafe" - -2. L1 Publication: - * Sequencer publishes blocks to Ethereum - * Blocks become "safe" once included in L1 - * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes) - -### Sequencer Trust - -The sequencer's role involves certain trust assumptions: - -* Can temporarily withhold transactions. -* May attempt to reorder transactions before L1 publication. -* Cannot modify or censor transactions once published to L1. -* Cannot affect finalized transactions. - -## Block and transaction validity in the OP Stack - -When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated; otherwise, it is discarded. Nodes execute valid blocks and update the rollup state accordingly. - -### Reorgs and finality - -A block's inclusion in a finalized Ethereum block ensures its finality. If a rollup block is included in a finalized Ethereum block, it cannot be reorged. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is handled by the **OP Stack** architecture. - -### Reorg Handling - -When L1 reorgs occur: - -1. Nodes detect the L1 reorg -2. Affected L2 blocks return to "unsafe" status -3. Sequencer typically republishes the same transactions -4. System returns to consistent state after reprocessing - -## The role of the proof system - -The proof system, is entirely separate from the core OP Stack protocol. It is an app-level validation system designed to ensure that certain claims about the rollup's state are correct. - -### What is a claim? - -A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `XYZ`. Other participants can challenge this claim if they believe it to be incorrect. - -### Fault proofs and challenges - -Challenges revolve around proving whether a given claim is valid. However, the outcome of a challenge does not affect the underlying chain. For example, if a claim about the state of the rollup at a certain block is proven wrong, it only affects the app-level functionality, not the OP Stack protocol. - -### Bridge Independence - -Important points about bridge systems: - -* Bridges are application-level constructs -* They operate independently of the core rollup protocol -* Bridge security doesn't affect L2 transaction validity -* Bridge failures don't cause L2 reorgs or state changes - -### Example: Custom bridges in OP Stack - -A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is app-level and not native to the OP Stack rollup. If there's an issue with the bridge, such as incorrect proof validation, it doesn't affect the rollup itself but impacts the subjective value of the bridged assets. - -## 7 days challenge period in OP Stack - -The 7 days challenge period exists to give time for challenges to be raised and resolved. While the rollup chain itself finalizes quickly (within 20 minutes), withdrawals from Layer 2 are delayed to allow for fault-proof validation. This ensures that malicious activity can be detected and challenged before it affects the system. - -### Why 7 days? - -The 7 day period is a reasonable time frame to allow participants to organize a response, potentially even organizing a hard fork on Layer 1 to address severe issues. In the context of the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup designs that may be built on top of the core protocol. - -### Withdrawal Delays vs. Finality - -One common misconception is confusing withdrawal delays with transaction finality: - -* Transaction finality occurs in approximately 20 minutes -* Withdrawal delays (often 7 days) are separate from transaction finality -* Withdrawal delays are application-level security features -* These delays affect only L1 withdrawals, not L2 transaction finality - -## Conclusion - -Transaction finality on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. diff --git a/pages/stack/protocol/rollup/finality.mdx b/pages/stack/transactions/transaction-finality.mdx similarity index 94% rename from pages/stack/protocol/rollup/finality.mdx rename to pages/stack/transactions/transaction-finality.mdx index fbbe50540..5c124d351 100644 --- a/pages/stack/protocol/rollup/finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -7,9 +7,11 @@ description: Learn about finality in OP Stack and the steps to achieve transacti import Image from 'next/image' import { Callout } from 'nextra/components' -# The OP Stack consensus mechanism +# Overview -The OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. +This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. + +OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. ## State Machines and Transaction Processing @@ -36,29 +38,17 @@ By publishing blocks on Ethereum, the OP Stack effectively outsources its consen * It simplifies the design and development process by eliminating the need for a separate consensus protocol. * Attack vectors, such as double-spends, are mitigated by Ethereum's security mechanisms. -## Transaction Finality States - -In the OP Stack, transaction finality progresses through three key stages: - -1. **Unsafe:** The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. - -2. **Safe:** The sequencer's batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. - -3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 20 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. - -Transaction Finality Diagram. - ## Sequencer Operations -The **sequencer** (block producer) processes transactions in the following steps: +The sequencer (block producer) processes transactions in the following steps: -1. **Pre-publishing Distribution:** +1. Pre-publishing Distribution: * The sequencer receives transactions from users. * It creates blocks containing these transactions. * It distributes these blocks to network nodes before L1 publication. * Nodes mark these blocks as "unsafe." -2. **L1 Publication:** +2. L1 Publication: * The sequencer publishes the blocks to Ethereum (L1). * Once included in L1, the blocks are marked as "safe." * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes). @@ -72,6 +62,18 @@ The sequencer operates with the following trust assumptions: * Once transactions are published on L1, the sequencer cannot modify or censor them. * The sequencer cannot affect finalized transactions. +## Transaction Finality States + +In the OP Stack, transaction finality progresses through three key stages: + +1. **Unsafe:** The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. + +2. **Safe:** The sequencer's batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. + +3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 20 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. + +Transaction Finality Diagram. + ## Block and Transaction Validity in the OP Stack When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the state as required. From 565bc82917db402203b4a5bef0f556041ab2b7e3 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:55:33 +0100 Subject: [PATCH 12/53] Updated structure --- .../transactions/transaction-finality.mdx | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 5c124d351..5af9272eb 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -14,21 +14,21 @@ This guide explains how transaction finality works in OP Stack, covering the fun OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. -## State Machines and Transaction Processing +## Transaction Processing State machines, such as the Ethereum Virtual Machine (EVM), rely on input lists (transactions) to evolve from one state to another. The order of the transactions is critical because incorrect ordering can lead to an invalid state. For example, if a user attempts to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making transaction ordering an essential aspect of consensus. -## Commutative vs. Non-Commutative Operations +### Commutative vs. Non-Commutative Operations Commutative operations allow the order of inputs to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Therefore, both the availability and the order of the transaction list are fundamental to ensuring the system's integrity. -## Consensus and Ordering +### Consensus and Ordering Consensus determines the valid chain or list of transactions. In the OP Stack, Ethereum's Proof of Stake (PoS) consensus mechanism is used to achieve transaction ordering and finality. -## Why Use Ethereum's Consensus? +### Why Use Ethereum's Consensus? By publishing blocks on Ethereum, the OP Stack effectively outsources its consensus mechanism. Instead of creating a separate consensus protocol, the OP Stack relies on Ethereum's ordering and finality guarantees. @@ -74,7 +74,7 @@ In the OP Stack, transaction finality progresses through three key stages: Transaction Finality Diagram. -## Block and Transaction Validity in the OP Stack +### Transaction Validity When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the state as required. @@ -103,6 +103,16 @@ A claim in the context of OP Stack is a statement asserting the state of the sys Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. +## 7-Day Challenge Period in OP Stack + +The 7-day challenge period provides time for challenges to be raised and resolved. +Although OP Stack finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. +This delay ensures that any malicious activity can be detected and addressed before it impacts the system. + +### Why Seven Days? + +The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. + ### Bridge Independence Key aspects of bridge systems include: @@ -116,16 +126,6 @@ Key aspects of bridge systems include: A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. -## 7-Day Challenge Period in OP Stack - -The 7-day challenge period provides time for challenges to be raised and resolved. -Although OP Stack finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. -This delay ensures that any malicious activity can be detected and addressed before it impacts the system. - -### Why Seven Days? - -The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. - ### Withdrawal Delays vs. Finality One common misconception is confusing withdrawal delays with transaction finality: From 1a136d6c7809abfe26eadde888d245f29c9733a6 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 17:58:12 +0100 Subject: [PATCH 13/53] resolved suggestions --- pages/stack/transactions/transaction-finality.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 5af9272eb..26d48d661 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -118,7 +118,7 @@ The 7-day challenge period is a reasonable time frame that allows participants t Key aspects of bridge systems include: * Bridges are application-level constructs. -* They operate independently from the core OP Stack protocol. +* They operate independently of the core OP Stack protocol. * Bridge security does not affect the validity of L2 transactions. * Bridge failures do not cause L2 reorgs or state changes. @@ -137,4 +137,4 @@ One common misconception is confusing withdrawal delays with transaction finalit ## Conclusion -Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While blocks finalize quickly, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms. +Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherits Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality. \ No newline at end of file From 16f6052cdb91956e655516cf0e72ecdf9ed25627 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 23 Oct 2024 18:01:59 +0100 Subject: [PATCH 14/53] fix lint errors --- pages/stack/transactions/transaction-finality.mdx | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 26d48d661..6d3fb3787 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -11,7 +11,7 @@ import { Callout } from 'nextra/components' This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. -OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. +OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. ## Transaction Processing @@ -105,9 +105,11 @@ Challenges focus on proving whether a given claim is valid. The outcome of a cha ## 7-Day Challenge Period in OP Stack -The 7-day challenge period provides time for challenges to be raised and resolved. -Although OP Stack finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. -This delay ensures that any malicious activity can be detected and addressed before it impacts the system. +The 7-day challenge period provides time for challenges to be raised and resolved. +Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: + +1. It allows time to validate and dispute the correctness of batches posted to Ethereum by the op-batcher, particularly important in scenarios like 51% attacks. +2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. ### Why Seven Days? @@ -137,4 +139,4 @@ One common misconception is confusing withdrawal delays with transaction finalit ## Conclusion -Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherits Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality. \ No newline at end of file +Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherits Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality. From 0139df2425258f9dfd71699bf09421fa4f347240 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:30:25 +0100 Subject: [PATCH 15/53] Update pages/stack/transactions/_meta.json Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 4ba3f6caa..8f37c3067 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,6 +1,6 @@ { "fees": "Transaction Fees", - "transaction-flow": "Transaction Flow", + "transaction-flow": "Transaction flow", "deposit-flow": "Deposit Flow", "withdrawal-flow": "Withdrawal Flow", "transaction-finality":"Transaction finality", From 186d94179f74ab8d9a934aa46d600d9655f9148d Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:31:10 +0100 Subject: [PATCH 16/53] Update pages/stack/transactions/_meta.json Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 8f37c3067..03517047c 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,7 +1,7 @@ { "fees": "Transaction Fees", "transaction-flow": "Transaction flow", - "deposit-flow": "Deposit Flow", + "deposit-flow": "Deposit flow", "withdrawal-flow": "Withdrawal Flow", "transaction-finality":"Transaction finality", "forced-transaction": "Forced Transaction" From 4eced457d8eef0ad35382331315816c58017dc4d Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:32:08 +0100 Subject: [PATCH 17/53] Update pages/stack/transactions/_meta.json Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 03517047c..44d26221b 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -2,7 +2,7 @@ "fees": "Transaction Fees", "transaction-flow": "Transaction flow", "deposit-flow": "Deposit flow", - "withdrawal-flow": "Withdrawal Flow", + "withdrawal-flow": "Withdrawal flow", "transaction-finality":"Transaction finality", "forced-transaction": "Forced Transaction" } From 062aa1a30e44f407da6619f1c563ab2b8cc2f82a Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:32:18 +0100 Subject: [PATCH 18/53] Update pages/stack/transactions/_meta.json Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 44d26221b..e171d7612 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -4,5 +4,5 @@ "deposit-flow": "Deposit flow", "withdrawal-flow": "Withdrawal flow", "transaction-finality":"Transaction finality", - "forced-transaction": "Forced Transaction" + "forced-transaction": "Forced transaction" } From fc42888c9833ccfed51efda12fa58d73da23204c Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:32:26 +0100 Subject: [PATCH 19/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 6d3fb3787..30b0d77de 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -9,7 +9,7 @@ import { Callout } from 'nextra/components' # Overview -This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. +This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. From c1ebce7c5df6b5ce5449e6da226aae71fb1a557d Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:32:51 +0100 Subject: [PATCH 20/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 30b0d77de..47e470f28 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -11,7 +11,7 @@ import { Callout } from 'nextra/components' This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. -OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. +The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. ## Transaction Processing From 2b3e7ed6ac8d833941352d05c814419bf3c5f506 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:33:13 +0100 Subject: [PATCH 21/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 47e470f28..551645b65 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -7,7 +7,7 @@ description: Learn about finality in OP Stack and the steps to achieve transacti import Image from 'next/image' import { Callout } from 'nextra/components' -# Overview +# Transaction finality This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. From 965f8b93c9e6454075827dd729aa273f271e7637 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:33:47 +0100 Subject: [PATCH 22/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 551645b65..77c017722 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -10,7 +10,6 @@ import { Callout } from 'nextra/components' # Transaction finality This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. - The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. From 8cf8f59d16b8d5a7cca741226c90ea8e61e240ec Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:34:09 +0100 Subject: [PATCH 23/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- .../transactions/transaction-finality.mdx | 23 ------------------- 1 file changed, 23 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 77c017722..ef13c81a9 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -13,29 +13,6 @@ This guide explains how transaction finality works in the OP Stack and addresses The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum. This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. -## Transaction Processing - -State machines, such as the Ethereum Virtual Machine (EVM), rely on input lists (transactions) to evolve from one state to another. The order of the transactions is critical because incorrect ordering can lead to an invalid state. - -For example, if a user attempts to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making transaction ordering an essential aspect of consensus. - -### Commutative vs. Non-Commutative Operations - -Commutative operations allow the order of inputs to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Therefore, both the availability and the order of the transaction list are fundamental to ensuring the system's integrity. - -### Consensus and Ordering - -Consensus determines the valid chain or list of transactions. In the OP Stack, Ethereum's Proof of Stake (PoS) consensus mechanism is used to achieve transaction ordering and finality. - -### Why Use Ethereum's Consensus? - -By publishing blocks on Ethereum, the OP Stack effectively outsources its consensus mechanism. Instead of creating a separate consensus protocol, the OP Stack relies on Ethereum's ordering and finality guarantees. - -### Key benefits of this approach: - -* OP Stack inherits Ethereum's security and transaction ordering properties. -* It simplifies the design and development process by eliminating the need for a separate consensus protocol. -* Attack vectors, such as double-spends, are mitigated by Ethereum's security mechanisms. ## Sequencer Operations From 60e368833036e3d7dab4501064b4bc3a9b0b4c31 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:36:33 +0100 Subject: [PATCH 24/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index ef13c81a9..e6c313153 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -42,7 +42,7 @@ The sequencer operates with the following trust assumptions: In the OP Stack, transaction finality progresses through three key stages: -1. **Unsafe:** The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. +1. **Unsafe:** The sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. 2. **Safe:** The sequencer's batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. From a19a6778ea07f8bdae0fc780aefb693a4c312ae3 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:36:50 +0100 Subject: [PATCH 25/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index e6c313153..87d1715d6 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -44,7 +44,7 @@ In the OP Stack, transaction finality progresses through three key stages: 1. **Unsafe:** The sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. -2. **Safe:** The sequencer's batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. +2. **Safe:** The batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. 3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 20 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. From 6340eddab979e9a03e801e13eb7879a5a9d98970 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:37:25 +0100 Subject: [PATCH 26/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 87d1715d6..22b30818a 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -46,7 +46,7 @@ In the OP Stack, transaction finality progresses through three key stages: 2. **Safe:** The batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. -3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 20 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. +3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 10-15 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. Transaction Finality Diagram. From ce345b5eca386f0414270e3c06c3eb42bb4a2f0b Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:37:42 +0100 Subject: [PATCH 27/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 22b30818a..84a6f830b 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -67,7 +67,7 @@ If an Ethereum reorganization (reorg) occurs: 3. The sequencer typically republishes the same transactions. 4. The system returns to a consistent state after reprocessing. -## The Role of the Proof System +## Common misconceptions The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the transaction state. From 1d70689374dce8256ad43e36cd03ae266aa56200 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:38:42 +0100 Subject: [PATCH 28/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 84a6f830b..b2686f536 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -50,9 +50,9 @@ In the OP Stack, transaction finality progresses through three key stages: Transaction Finality Diagram. -### Transaction Validity +### Transaction validity -When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the state as required. +When a transaction is submitted to the network, it is either valid or invalid. If the transaction is valid, the sequencer puts it in a block. If it is invalid, the transaction is discarded. There is no way the sequencer can write an invalid transaction to a new block. ### Reorgs and Finality From b9acf97fc358176da86a384604192ec46c1bd5da Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:46:11 +0100 Subject: [PATCH 29/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- .../transactions/transaction-finality.mdx | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index b2686f536..8c29e05fb 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -71,26 +71,20 @@ If an Ethereum reorganization (reorg) occurs: The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the transaction state. -### What Is a Claim? +### The role of proof system -A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. - -### Fault Proofs and Challenges +The following is a quick refresher on the Fault Proof System. It is a system designed to ensure the accuracy of certain claims about the transaction state on the L2. -Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. +A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. -## 7-Day Challenge Period in OP Stack +Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the application level functionality and does not alter the OP Stack protocol. -The 7-day challenge period provides time for challenges to be raised and resolved. +The challenge period provides time for challenges to be raised and resolved. Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: -1. It allows time to validate and dispute the correctness of batches posted to Ethereum by the op-batcher, particularly important in scenarios like 51% attacks. +1. It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer. 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. -### Why Seven Days? - -The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. - ### Bridge Independence Key aspects of bridge systems include: From f6f4a3850d725ee9ccd68807274cce532851c3b3 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:46:48 +0100 Subject: [PATCH 30/53] resolved comments --- .../transactions/transaction-finality.mdx | 44 ++++++------------- 1 file changed, 13 insertions(+), 31 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index ef13c81a9..f1c1c0144 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -7,29 +7,14 @@ description: Learn about finality in OP Stack and the steps to achieve transacti import Image from 'next/image' import { Callout } from 'nextra/components' -# Transaction finality +# Overview -This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. -The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum. -This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. - - -## Sequencer Operations - -The sequencer (block producer) processes transactions in the following steps: - -1. Pre-publishing Distribution: - * The sequencer receives transactions from users. - * It creates blocks containing these transactions. - * It distributes these blocks to network nodes before L1 publication. - * Nodes mark these blocks as "unsafe." +This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. -2. L1 Publication: - * The sequencer publishes the blocks to Ethereum (L1). - * Once included in L1, the blocks are marked as "safe." - * Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes). +OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. +This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. -### Sequencer Trust Assumptions +## Sequencer trust assumptions The sequencer operates with the following trust assumptions: @@ -38,7 +23,7 @@ The sequencer operates with the following trust assumptions: * Once transactions are published on L1, the sequencer cannot modify or censor them. * The sequencer cannot affect finalized transactions. -## Transaction Finality States +## Transaction finality states In the OP Stack, transaction finality progresses through three key stages: @@ -50,15 +35,16 @@ In the OP Stack, transaction finality progresses through three key stages: Transaction Finality Diagram. -### Transaction Validity - -When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the state as required. +## Common misconceptions -### Reorgs and Finality +The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. The reality is the OP Stack transaction finality takes minutes, not 7-days. +This section detangles the concept of transaction finality and the Fault Proof System's challenger mechanism -Once a block is included in a finalized Ethereum block, it cannot be reorganized. Therefore, blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is managed by the OP Stack architecture. +### Transaction validity +When a transaction is submitted to the network, it is either valid or invalid. If the transaction is valid, the sequencer puts it in a block. If it is invalid, the transaction is discarded. There is no way the sequencer can write an invalid transaction to a new block. -### Handling Reorgs +### Reorgs and finality +Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. If an Ethereum reorganization (reorg) occurs: @@ -67,10 +53,6 @@ If an Ethereum reorganization (reorg) occurs: 3. The sequencer typically republishes the same transactions. 4. The system returns to a consistent state after reprocessing. -## The Role of the Proof System - -The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the transaction state. - ### What Is a Claim? A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. From 867fb4c3809c9c401a96f85c9a1a9aebd19c3d7c Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:51:58 +0100 Subject: [PATCH 31/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 8c29e05fb..23ce338ec 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -85,7 +85,7 @@ Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day 1. It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer. 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. -### Bridge Independence +### Bridge independence Key aspects of bridge systems include: From 8a9ecd0853749b0fc4e008fbd46d2774a213d204 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:52:49 +0100 Subject: [PATCH 32/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 23ce338ec..0dd679145 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -94,9 +94,7 @@ Key aspects of bridge systems include: * Bridge security does not affect the validity of L2 transactions. * Bridge failures do not cause L2 reorgs or state changes. -### Example: Custom Bridges in OP Stack - -A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. +For example, a custom bridge might be developed to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. ### Withdrawal Delays vs. Finality From b2cac6a1b0341d129b48a5414335d6bd4e2e7942 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 11:52:55 +0100 Subject: [PATCH 33/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: soyboy <85043086+sbvegan@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 0dd679145..39bc62fd0 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -96,7 +96,7 @@ Key aspects of bridge systems include: For example, a custom bridge might be developed to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. -### Withdrawal Delays vs. Finality +### Withdrawal delays vs. finality One common misconception is confusing withdrawal delays with transaction finality: From d27bae68e650301d166b09957b9141c28ab92038 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 12:17:31 +0100 Subject: [PATCH 34/53] updated the docs --- .../transactions/transaction-finality.mdx | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index f14ab7c3b..394239cbe 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -7,12 +7,11 @@ description: Learn about finality in OP Stack and the steps to achieve transacti import Image from 'next/image' import { Callout } from 'nextra/components' -# Overview +# Transaction finality -This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. +This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. -OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. -This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer. +The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum. ## Sequencer trust assumptions @@ -39,6 +38,11 @@ In the OP Stack, transaction finality progresses through three key stages: When a transaction is submitted to the network, it is either valid or invalid. If the transaction is valid, the sequencer puts it in a block. If it is invalid, the transaction is discarded. There is no way the sequencer can write an invalid transaction to a new block. +## Common misconceptions + +The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. +The reality is the OP Stack transaction finality takes minutes, not over a week. This section detangles the concept of transaction finality and the Fault Proof System's challenger mechanism. + ### Reorgs and finality Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. @@ -49,13 +53,9 @@ If an Ethereum reorganization (reorg) occurs: 3. The sequencer typically republishes the same transactions. 4. The system returns to a consistent state after reprocessing. -## Common misconceptions - -The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the transaction state. - ### The role of proof system -The following is a quick refresher on the Fault Proof System. It is a system designed to ensure the accuracy of certain claims about the transaction state on the L2. +The Fault Proof System is designed to ensure the accuracy of certain claims about the transaction state on the L2. A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. @@ -67,6 +67,15 @@ Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day 1. It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer. 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. +### Withdrawal delays vs. finality + +One common misconception is confusing withdrawal delays with transaction finality: + +* Transaction finality occurs in approximately 20 minutes. +* Withdrawal delays (often 7 days) are separate from transaction finality. +* Withdrawal delays are application-level security features. +* These delays affect only L1 withdrawals, not L2 transaction finality. + ### Bridge independence Key aspects of bridge systems include: @@ -78,15 +87,6 @@ Key aspects of bridge systems include: For example, a custom bridge might be developed to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. -### Withdrawal delays vs. finality - -One common misconception is confusing withdrawal delays with transaction finality: - -* Transaction finality occurs in approximately 20 minutes. -* Withdrawal delays (often 7 days) are separate from transaction finality. -* Withdrawal delays are application-level security features. -* These delays affect only L1 withdrawals, not L2 transaction finality. - ## Conclusion Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherits Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality. From b71df34824fbd4cd8b6e5ddeef31a7c54290d3a7 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 12:21:21 +0100 Subject: [PATCH 35/53] removed wrong word --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 394239cbe..5caa97d12 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -41,7 +41,7 @@ When a transaction is submitted to the network, it is either valid or invalid. I ## Common misconceptions The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. -The reality is the OP Stack transaction finality takes minutes, not over a week. This section detangles the concept of transaction finality and the Fault Proof System's challenger mechanism. +The reality is the OP Stack transaction finality takes minutes, not over a week. This section explains transaction finality and the Fault Proof System's challenge mechanism. ### Reorgs and finality Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. From aacd64ff0dd514aaaf7f4273fa8aef2f9c843eb7 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 13:38:52 +0100 Subject: [PATCH 36/53] resolved comments --- pages/stack/transactions/_meta.json | 2 +- .../transactions/transaction-finality.mdx | 24 +++++++++---------- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index e171d7612..1e8b53eb9 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,8 +1,8 @@ { "fees": "Transaction Fees", "transaction-flow": "Transaction flow", + "transaction-finality":"Transaction finality", "deposit-flow": "Deposit flow", "withdrawal-flow": "Withdrawal flow", - "transaction-finality":"Transaction finality", "forced-transaction": "Forced transaction" } diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 5caa97d12..834f7f8b7 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -13,15 +13,6 @@ This guide explains how transaction finality works in the OP Stack and addresses The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a layer 2 blockchain by reading the finalized state on Ethereum. -## Sequencer trust assumptions - -The sequencer operates with the following trust assumptions: - -* It can temporarily withhold transactions. -* It may attempt to reorder transactions before L1 publication. -* Once transactions are published on L1, the sequencer cannot modify or censor them. -* The sequencer cannot affect finalized transactions. - ## Transaction finality states In the OP Stack, transaction finality progresses through three key stages: @@ -38,6 +29,15 @@ In the OP Stack, transaction finality progresses through three key stages: When a transaction is submitted to the network, it is either valid or invalid. If the transaction is valid, the sequencer puts it in a block. If it is invalid, the transaction is discarded. There is no way the sequencer can write an invalid transaction to a new block. +## Sequencer trust assumptions + +The sequencer operates with the following trust assumptions: + +* It can temporarily withhold transactions. +* It may attempt to reorder transactions before L1 publication. +* Once transactions are published on L1, the sequencer cannot modify or censor them. +* The sequencer cannot affect finalized transactions. + ## Common misconceptions The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. @@ -55,11 +55,11 @@ If an Ethereum reorganization (reorg) occurs: ### The role of proof system -The Fault Proof System is designed to ensure the accuracy of certain claims about the transaction state on the L2. +The Fault Proof System is designed to ensure the accuracy of certain claims about the transaction state on the L2. It provides a way to prove messages from L2 to L1 are correct. It does not have to do with transaction finality. -A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. +A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000 a certain address has all of the ether on the entire L2. If other participants believe this claim to be incorrect, they can challenge it. -Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the application level functionality and does not alter the OP Stack protocol. +Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about a certain address owning all the ether on the L2 is proven wrong, that address would not be able to move the ether from L2 to their address on L1. The challenge period provides time for challenges to be raised and resolved. Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: From 71ea8fc85c728dbc3b02c2c78a1ff675c982f856 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 13:41:38 +0100 Subject: [PATCH 37/53] Used sentence case in meta json file --- pages/stack/transactions/_meta.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 1e8b53eb9..9fee5861a 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,5 +1,5 @@ { - "fees": "Transaction Fees", + "fees": "Transaction fees", "transaction-flow": "Transaction flow", "transaction-finality":"Transaction finality", "deposit-flow": "Deposit flow", From d7bec268a0946dcffc99752490bce48c870bb40d Mon Sep 17 00:00:00 2001 From: soyboy <85043086+sbvegan@users.noreply.github.com> Date: Thu, 24 Oct 2024 05:41:59 -0700 Subject: [PATCH 38/53] Update pages/stack/transactions/transaction-finality.mdx --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 834f7f8b7..19d3a686f 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -49,7 +49,7 @@ Once a transaction is included in a finalized Ethereum block, it cannot be reorg If an Ethereum reorganization (reorg) occurs: 1. L2 nodes detect the L1 reorg. -2. Affected L2 blocks revert to an "unsafe" status. +2. Affected `safe` L2 blocks revert to an `unsafe` status. 3. The sequencer typically republishes the same transactions. 4. The system returns to a consistent state after reprocessing. From 04bb7e9f157af1ca4cc1152ff2aef8d8a82b4056 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 24 Oct 2024 13:53:51 +0100 Subject: [PATCH 39/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 19d3a686f..4f7a8ec8c 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -71,7 +71,7 @@ Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day One common misconception is confusing withdrawal delays with transaction finality: -* Transaction finality occurs in approximately 20 minutes. +* Transaction finality occurs in approximately 10–15 minutes. * Withdrawal delays (often 7 days) are separate from transaction finality. * Withdrawal delays are application-level security features. * These delays affect only L1 withdrawals, not L2 transaction finality. From e7556191a82a114d4652933d20460b5ab2f201c2 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 30 Oct 2024 13:14:50 +0100 Subject: [PATCH 40/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: smartcontracts --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 4f7a8ec8c..5fb2d121b 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -46,7 +46,7 @@ The reality is the OP Stack transaction finality takes minutes, not over a week. ### Reorgs and finality Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. -If an Ethereum reorganization (reorg) occurs: +If an Ethereum reorganization (reorg) were to occur *before* finality: 1. L2 nodes detect the L1 reorg. 2. Affected `safe` L2 blocks revert to an `unsafe` status. From f9a4bb0917d444c482f02ae26b5abf543dfb618e Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 30 Oct 2024 14:44:07 +0100 Subject: [PATCH 41/53] updated text --- .../transactions/transaction-finality.mdx | 43 ++++++++++++------- words.txt | 9 ++++ 2 files changed, 37 insertions(+), 15 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 834f7f8b7..4423a504a 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -17,45 +17,45 @@ The OP Stack derives its security from Ethereum by utilizing Ethereum's consensu In the OP Stack, transaction finality progresses through three key stages: -1. **Unsafe:** The sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. +1. **Unsafe:** The Sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. -2. **Safe:** The batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction. +2. **Safe:** The Sequencer posts the transaction data to L1. At this point, any L2 node can derive the transaction. -3. **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 10-15 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized. +3. **Finalized:** Transactions are generally finalized on Ethereum when 2/3 of validators sign off on two consecutive checkpoints. This typically occurs within approximately two epochs, or around 65 blocks (10-15 minutes), but may take longer under adverse network conditions. This ensures that L1 data remains secure and unlikely to be reorganized. Transaction Finality Diagram. ### Transaction validity -When a transaction is submitted to the network, it is either valid or invalid. If the transaction is valid, the sequencer puts it in a block. If it is invalid, the transaction is discarded. There is no way the sequencer can write an invalid transaction to a new block. +When a transaction is submitted to the network, it undergoes validation. If the transaction is valid, the Sequencer includes it in a block. If it is invalid, it may still be proposed by the Sequencer, but the rest of the network will reject the block containing the invalid transaction, ensuring only valid transactions are finalized. ## Sequencer trust assumptions -The sequencer operates with the following trust assumptions: +The Sequencer operates with the following trust assumptions: * It can temporarily withhold transactions. * It may attempt to reorder transactions before L1 publication. -* Once transactions are published on L1, the sequencer cannot modify or censor them. -* The sequencer cannot affect finalized transactions. +* Once transactions are published on L1 and finality is reached, the Sequencer cannot modify or censor them. However, until finality, transactions are theoretically subject to reorgs. ## Common misconceptions -The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. +The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. The reality is the OP Stack transaction finality takes minutes, not over a week. This section explains transaction finality and the Fault Proof System's challenge mechanism. ### Reorgs and finality -Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. -If an Ethereum reorganization (reorg) occurs: +Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. -1. L2 nodes detect the L1 reorg. -2. Affected L2 blocks revert to an "unsafe" status. -3. The sequencer typically republishes the same transactions. -4. The system returns to a consistent state after reprocessing. +If an Ethereum reorganization (reorg) occurs, it affects applications on the OP Stack, such as the Optimism bridge, which uses the OP Stack's proof system to ensure transaction integrity: + +1. Detection: L2 nodes detect the L1 reorg, flagging the Optimism bridge's related transactions for re-evaluation. +2. State Adjustment: The L2 blocks impacted by the reorg revert to an "unsafe" status. +3. Transaction Re-publication: The Sequencer typically republishes the same transactions for the bridge, using the proof system to re-establish transaction validity. +4. System Restoration: After reprocessing, the system stabilizes, restoring a consistent state for bridge-related operations without impacting the rollup's core finalized state.1 ### The role of proof system -The Fault Proof System is designed to ensure the accuracy of certain claims about the transaction state on the L2. It provides a way to prove messages from L2 to L1 are correct. It does not have to do with transaction finality. +The Fault Proof System is used by bridge contracts on L1 to verify claims that users make about the state of L2 for the purpose of facilitating user withdrawals of certain bridged assets from L2 to L1. A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000 a certain address has all of the ether on the entire L2. If other participants believe this claim to be incorrect, they can challenge it. @@ -67,13 +67,26 @@ Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day 1. It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer. 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. +During this 7-day period: + +* If no challenge is raised: The posted state root is confirmed as valid, and users can proceed with their withdrawals or related transactions on Ethereum, completing the cross-chain process smoothly. + +* If a successful challenge occurs: The claim on the state root is invalidated, blocking any withdrawals based on that incorrect state root. This ensures that any invalid state does not impact the L2 chain's integrity or user assets. + Notably, this challenge mechanism is app-level and does not trigger reorganization or alter the core L2 chain's finalized state. + ### Withdrawal delays vs. finality One common misconception is confusing withdrawal delays with transaction finality: * Transaction finality occurs in approximately 20 minutes. + +* Withdrawal delays are an application-level security feature specific to the Optimism bridge. These delays impact only L1 withdrawals and do not affect the L2 protocol's transaction finality. + This distinction ensures that the core protocol maintains efficiency and quick finalization for Layer 2 transactions. + * Withdrawal delays (often 7 days) are separate from transaction finality. + * Withdrawal delays are application-level security features. + * These delays affect only L1 withdrawals, not L2 transaction finality. ### Bridge independence diff --git a/words.txt b/words.txt index b86d09017..608ea2b89 100644 --- a/words.txt +++ b/words.txt @@ -11,6 +11,7 @@ Allocs allocs altda ANDI +Ankr Apeworx Arweave authrpc @@ -146,6 +147,7 @@ Holesky holesky IGNOREPRICE ignoreprice +Immunefi implicity Inator inator @@ -194,6 +196,7 @@ minsuggestedpriorityfee Mintable Mintplex MIPSEVM +Mitigations Monitorism Moralis Mordor @@ -287,6 +290,8 @@ Protip Proxied proxyd pseudorandomly +Pyth +Pyth's QRNG Quicknode quicknode @@ -318,6 +323,9 @@ safedb Schnorr secp SELFDESTRUCT +SEPOLIA +Sepolia +sepolia seqnr SEQUENCERHTTP sequencerhttp @@ -383,6 +391,7 @@ VMDEBUG vmdebug VMODULE vmodule +voxel wagmi Warpcast XORI From 8c54927748d97105bc184e3f7d7b04088f2579c3 Mon Sep 17 00:00:00 2001 From: Kelvin Fichter Date: Sat, 2 Nov 2024 01:08:32 +0700 Subject: [PATCH 42/53] feat: miscellanous improvements to finality doc Basically a rewrite. --- .../transactions/transaction-finality.mdx | 95 ++++++++----------- 1 file changed, 39 insertions(+), 56 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index faa30642d..3c74c9853 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -1,7 +1,7 @@ --- title: Transaction Finality lang: en-US -description: Learn about finality in OP Stack and the steps to achieve transaction settlement. +description: Learn when transactions on OP Stack chains can be considered finalized. --- import Image from 'next/image' @@ -9,94 +9,77 @@ import { Callout } from 'nextra/components' # Transaction finality -This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. +This page explains when transactions on OP Stack chains can be considered "finalized" and addresses common misconceptions about transaction finality on the OP Stack. -The OP Stack derives its security from Ethereum by utilizing Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack derives a L2 blockchain by reading the finalized state on Ethereum. +## Basics of finality -## Transaction finality states +Transaction "finality" is a term used to describe the point at which a transaction is irreversible under certain assumptions. For example, Ethereum transactions are considered finalized when certain conditions in Ethereum's consensus mechanism are met. Many applications built on top of Ethereum make use of this property when making certain decisions, like crediting a user's account when the user makes a deposit to an exchange. -In the OP Stack, transaction finality progresses through three key stages: +## OP Stack finality -1. **Unsafe:** The Sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed. +OP Stack chains in the Standard Configuration are Rollups that utilize Ethereum's consensus mechanism to order and finalize transactions instead of running an entirely separate consensus protocol. As a result, chains using the OP Stack inherit the ordering and finality properties of Ethereum. -2. **Safe:** The Sequencer posts the transaction data to L1. At this point, any L2 node can derive the transaction. +## Steps to finality -3. **Finalized:** Transactions are generally finalized on Ethereum when 2/3 of validators sign off on two consecutive checkpoints. This typically occurs within approximately two epochs, or around 65 blocks (10-15 minutes), but may take longer under adverse network conditions. This ensures that L1 data remains secure and unlikely to be reorganized. +Transactions on OP Stack chains follow a simple process to finality: -Transaction Finality Diagram. - -### Transaction validity - -When a transaction is submitted to the network, it undergoes validation. If the transaction is valid, the Sequencer includes it in a block. If it is invalid, it may still be proposed by the Sequencer, but the rest of the network will reject the block containing the invalid transaction, ensuring only valid transactions are finalized. +1. A user submits a transaction to the network, which is forwarded to the Sequencer. +1. The Sequencer includes the transaction in a block and distributes the block over a public p2p network. The user's transaction is now considered to be in a known but **"unsafe"** state. Here, "unsafe" is a technical term used to describe the fact that the transaction has been included in a block whose data has not yet been posted to Ethereum. This typically takes just a few seconds. +1. The Sequencer publishes the data for this block to Ethereum either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once this transaction is included in an Ethereum block, the user's transaction is considered to be in a **"safe"** state. This step typically takes 5-10 minutes. +1. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the user's transaction is considered to be in a **"finalized"** state. Ethereum finalization typically takes ~65 Ethereum blocks or ~13 minutes but may take longer under certain network conditions. Finality here is entirely dependent on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). -## Sequencer trust assumptions +TODO: Fix this so it has the right numbers -The Sequencer operates with the following trust assumptions: - -* It can temporarily withhold transactions. -* It may attempt to reorder transactions before L1 publication. -* Once transactions are published on L1 and finality is reached, the Sequencer cannot modify or censor them. However, until finality, transactions are theoretically subject to reorgs. +Transaction Finality Diagram. ## Common misconceptions -The biggest misconception about transaction finality is that a transaction needs to wait for the entire challenge window to become finalized. -The reality is the OP Stack transaction finality takes minutes, not over a week. This section explains transaction finality and the Fault Proof System's challenge mechanism. - -### Reorgs and finality +### Misconception: transactions take 7 days to finalize -Once a transaction is included in a finalized Ethereum block, it cannot be reorganized. +It's common to hear that transactions on OP Stack chains take 7 days to finalize. **This is incorrect.** Transactions on OP Stack chains become finalized when their data is included in a finalized Ethereum block. This typically takes ~20-30 minutes from the time the transaction is submitted. To reorg a finalized OP Stack chain transaction, you would have to be able to reorg the finalized Ethereum block that transaction's data is included within. -If an Ethereum reorganization (reorg) occurs, it affects applications on the OP Stack, such as the Optimism bridge, which uses the OP Stack's proof system to ensure transaction integrity: +Confusion about this fact commonly stems from the OP Stack's Standard Bridge design which includes a 7 day delay on *withdrawals* of ETH and other ERC-20 tokens from the bridge. This means that it takes a minimum of 7 days to move tokens from an OP Stack chain to Ethereum when using the Standard Bridge. The 7 day withdrawal delay applies to only to these withdrawals and has no impact the speed of finality on the OP Stack chain. -1. Detection: L2 nodes detect the L1 reorg, flagging the Optimism bridge's related transactions for re-evaluation. -2. State Adjustment: The L2 blocks impacted by the reorg revert to an "unsafe" status. -3. Transaction Re-publication: The Sequencer typically republishes the same transactions for the bridge, using the proof system to re-establish transaction validity. -4. System Restoration: After reprocessing, the system stabilizes, restoring a consistent state for bridge-related operations without impacting the rollup's core finalized state.1 +### Misconception: challenges in the Standard Bridge can cause a chain reorg -### The role of proof system +Another common misconception related to the misconception that [finalization takes 7 days](#misconception-transactions-take-7-days-to-finalize) is the idea that **Fault Proof challenges** created in response to withdrawals within the Standard Bridge can cause an OP Stack chain to reorganize itself (reorg). **This is not correct.** OP Stack transactions are never reorganized in response to any Fault Proof challenge. -The Fault Proof System is used by bridge contracts on L1 to verify claims that users make about the state of L2 for the purpose of facilitating user withdrawals of certain bridged assets from L2 to L1. +The Standard Bridge is a bridge application that is included by default with any OP Stack chain and connects the chain to its "parent" blockchain (usually Ethereum). The Standard Bridge takes advantage of the special relationship between a Rollup and its parent blockchain to be able to provide a high level of security for any ETH and ERC-20 tokens moved through the bridge. -A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000 a certain address has all of the ether on the entire L2. If other participants believe this claim to be incorrect, they can challenge it. +Users that want to send ETH or ERC-20 tokens from the OP Stack chain to Ethereum through the Standard Bridge must first *burn* these ETH or ERC-20 tokens on the OP Stack chain. The user can then create a **withdrawal claim** on Ethereum that *claims* that they have indeed burned these tokens on the OP Stack chain. -Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about a certain address owning all the ether on the L2 is proven wrong, that address would not be able to move the ether from L2 to their address on L1. +Since the Standard Bridge is a smart contract on Ethereum and smart contracts can't run a whole node for an OP Stack chain, it has no way to immediately determine if a given withdrawal claim actually corresponds to real tokens being burned on the OP Stack chain. Instead, the Standard Bridge delays a claim by 7 days to allow time for the OP Stack Fault Proof system to filter out any "bad" withdrawal claims. -The challenge period provides time for challenges to be raised and resolved. -Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: +Anyone can make any sort of withdrawal claim at any time because the bridge has no way to immediately distinguish a good claim from a bad one. Challenges simply remove a bad withdrawal claim without any other impact to the Standard Bridge or the underlying OP Stack chain. -1. It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer. -2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. +TODO: It'd be really fun to have a button that (for the bond cost of 0.08 ETH) creates a bad withdrawal claim for all of the ETH in the bridge. Users would be able to see first hand how their claim gets deleted and nothing else happens. -During this 7-day period: +### Misconception: the Sequencer can always reorg the chain -* If no challenge is raised: The posted state root is confirmed as valid, and users can proceed with their withdrawals or related transactions on Ethereum, completing the cross-chain process smoothly. +Sequencers play an important role in an OP Stack chain. The Sequencer acts as the block producer for the chain and quickly creates blocks as it receives user transactions. Here we'll address the common misconception that the Sequencer can cause reorganizations of the OP Stack chain over long periods of time. -* If a successful challenge occurs: The claim on the state root is invalidated, blocking any withdrawals based on that incorrect state root. This ensures that any invalid state does not impact the L2 chain's integrity or user assets. - Notably, this challenge mechanism is app-level and does not trigger reorganization or alter the core L2 chain's finalized state. +The OP Stack expects the Sequencer to produce a block every 1 or 2 seconds depending on the configuration of the chain. Since this 1 or 2 second block time is less than Ethereum's 12 second block time, there will always be some time before a Sequencer's block can be published to Ethereum. -### Withdrawal delays vs. finality +Sequencers **can** reorganize blocks *before* they are published to Ethereum, which is why OP Stack chain nodes consider these blocks to be **"unsafe"**. Although "unsafe" blocks are typically not reorganized, it is important for applications to understand that a reorganization is always possible. Reorgs of "unsafe" blocks *have* previously occurred during temporary Sequencer outages. -One common misconception is confusing withdrawal delays with transaction finality: +Reorganization becomes significantly more difficult once the Sequencer publishes block data to Ethereum. At this point, the Sequencer would have to *intentionally* cause a reorg of Ethereum itself. Given the difficulty required to trigger such a reorg, OP Stack nodes are programmed to consider transactions to be **"safe"** when this condition is reached. -* Transaction finality occurs in approximately 20 minutes. +Once block data for the OP Stack chain is included in a finalized Ethereum block, the Sequencer **cannot** cause a reorganization of the OP Stack chain without violating finality in Ethereum itself. Applications built on top of Ethereum typically operate under the assumption that such a violation is not possible. -* Withdrawal delays are an application-level security feature specific to the Optimism bridge. +In summary: -* These delays impact only L1 withdrawals and do not affect the L2 protocol's transaction finality. - -* This distinction ensures that the core protocol maintains efficiency and quick finalization for L2 transactions. +* The Sequencer **can** cause a reorganization of **"unsafe"** blocks that have not yet been published to Ethereum (within ~5-10 minutes). +* The Sequencer **could** cause a reorgnization of **"safe** blocks that have been published to Ethereum but not yet included in a finalized Ethereum block (within ~15-30 minutes). To do this, the Sequencer would need to be able to intentionally cause a reorganization of Ethereum itself. +* The Sequencer **cannot** cause a reorganizaton of **"finalized"** blocks that have been included in a finalized Ethereum block (after ~15-30 minutes) without violating Ethereum's finality guarantees. -### Bridge independence +### Misconception: Ethereum reorgs will cause reorgs on the OP Stack chain -Key aspects of bridge systems include: +When we touched on the misconception that the [Sequencer can always reorganize the chain](#misconception-the-sequencer-can-always-reorganize-the-chain) above we noted that transactions that are **"unsafe"** or **"safe"** could be impacted by reorganizations of Ethereum itself. Although it's unlikely for the Sequencer to be able to affect such a reorganization intentionally, Ethereum reorganizations *do* occur from time to time. -* Bridges are application-level constructs. -* They operate independently of the core OP Stack protocol. -* Bridge security does not affect the validity of L2 transactions. -* Bridge failures do not cause L2 reorgs or state changes. +When a reorganization occurs on Ethereum, assuming that the Sequencer is not intentionally triggering this reorg, the OP Stack chain will attempt to gracefully recover. OP Stack nodes will automatically downgrade **"safe"** transactions back into **"unsafe"** transactions if necessary. At the same time, the Sequencer will begin the process of publishing transaction data again to re-establish the original chain. -For example, a custom bridge might be developed to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. +Graceful handling of Ethereum reorgs means that an OP Stack chain will typically recover without experiencing any sort of reorganization itself. In rare cases, extreme Ethereum network conditions *could* cause reorganizations of an OP Stack chain, but **"finalized"** OP Stack chain transactions can **never** be reorganized. ## Conclusion -Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherits Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality. +Transaction finality in the OP Stack is a lot simpler than it seems. OP Stack chains utilize Ethereum for consensus and inherit Ethereum's finality guarantees as a result. Once your node reports an OP Stack chain transaction as **"finalized"**, it can't be reversed. From eda6ab755faec1e5a6bbdcc695280fa7067670d4 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 6 Nov 2024 11:56:30 +0100 Subject: [PATCH 43/53] Removed passive tones, and rephrased contents --- .../transactions/transaction-finality.mdx | 66 +++++++------------ words.txt | 9 ++- 2 files changed, 31 insertions(+), 44 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 3c74c9853..2ffbc8c6a 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -1,5 +1,5 @@ --- -title: Transaction Finality +title: Transaction finality lang: en-US description: Learn when transactions on OP Stack chains can be considered finalized. --- @@ -9,24 +9,24 @@ import { Callout } from 'nextra/components' # Transaction finality -This page explains when transactions on OP Stack chains can be considered "finalized" and addresses common misconceptions about transaction finality on the OP Stack. +This guide explains when transactions on OP Stack chains are considered finalized and addresses common misconceptions about transaction finality on the OP Stack. ## Basics of finality -Transaction "finality" is a term used to describe the point at which a transaction is irreversible under certain assumptions. For example, Ethereum transactions are considered finalized when certain conditions in Ethereum's consensus mechanism are met. Many applications built on top of Ethereum make use of this property when making certain decisions, like crediting a user's account when the user makes a deposit to an exchange. +Transaction finality refers to the point at which a transaction becomes irreversible under certain assumptions. For example, Ethereum transactions are considered finalized when specific conditions in Ethereum's consensus mechanism are met. Many applications built on Ethereum rely on this property when making decisions, such as crediting a user's account after they deposit funds. ## OP Stack finality -OP Stack chains in the Standard Configuration are Rollups that utilize Ethereum's consensus mechanism to order and finalize transactions instead of running an entirely separate consensus protocol. As a result, chains using the OP Stack inherit the ordering and finality properties of Ethereum. +OP Stack chains in the standard configuration are Rollups that use Ethereum's consensus mechanism to order and finalize transactions rather than running a separate consensus protocol. Therefore, OP Stack chains inherit Ethereum's ordering and finality properties. ## Steps to finality -Transactions on OP Stack chains follow a simple process to finality: +Transactions on OP Stack chains go through the following process to reach finality: -1. A user submits a transaction to the network, which is forwarded to the Sequencer. -1. The Sequencer includes the transaction in a block and distributes the block over a public p2p network. The user's transaction is now considered to be in a known but **"unsafe"** state. Here, "unsafe" is a technical term used to describe the fact that the transaction has been included in a block whose data has not yet been posted to Ethereum. This typically takes just a few seconds. -1. The Sequencer publishes the data for this block to Ethereum either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once this transaction is included in an Ethereum block, the user's transaction is considered to be in a **"safe"** state. This step typically takes 5-10 minutes. -1. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the user's transaction is considered to be in a **"finalized"** state. Ethereum finalization typically takes ~65 Ethereum blocks or ~13 minutes but may take longer under certain network conditions. Finality here is entirely dependent on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). +1. A user submits a transaction to the network, which forwards it to the Sequencer. +2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**. A technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes only a few seconds. +3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is **"safe"**. This step usually takes 5–10 minutes. +4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 65 Ethereum blocks, or approximately 13 minutes, but may take longer under certain network conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). TODO: Fix this so it has the right numbers @@ -34,52 +34,36 @@ TODO: Fix this so it has the right numbers ## Common misconceptions -### Misconception: transactions take 7 days to finalize +### Transactions take 7 days to finalize -It's common to hear that transactions on OP Stack chains take 7 days to finalize. **This is incorrect.** Transactions on OP Stack chains become finalized when their data is included in a finalized Ethereum block. This typically takes ~20-30 minutes from the time the transaction is submitted. To reorg a finalized OP Stack chain transaction, you would have to be able to reorg the finalized Ethereum block that transaction's data is included within. +A common misconception is that transactions on OP Stack chains take 7 days to finalize. **This is incorrect.** Transactions on OP Stack chains become finalized when their data is included in a finalized Ethereum block, typically around 20–30 minutes after submission. To reorg a finalized OP Stack chain transaction, a reorg of the corresponding Ethereum block would be required. -Confusion about this fact commonly stems from the OP Stack's Standard Bridge design which includes a 7 day delay on *withdrawals* of ETH and other ERC-20 tokens from the bridge. This means that it takes a minimum of 7 days to move tokens from an OP Stack chain to Ethereum when using the Standard Bridge. The 7 day withdrawal delay applies to only to these withdrawals and has no impact the speed of finality on the OP Stack chain. +This misconception often arises due to the OP Stack's Standard Bridge, which includes a 7-day delay on *withdrawals* of ETH and ERC-20 tokens. Withdrawing tokens from an OP Stack chain to Ethereum using the Standard Bridge requires a minimum 7-day wait. This delay affects only withdrawals and does not impact transaction finality on the OP Stack chain. -### Misconception: challenges in the Standard Bridge can cause a chain reorg +### Challenges in the Standard Bridge can cause a chain reorg -Another common misconception related to the misconception that [finalization takes 7 days](#misconception-transactions-take-7-days-to-finalize) is the idea that **Fault Proof challenges** created in response to withdrawals within the Standard Bridge can cause an OP Stack chain to reorganize itself (reorg). **This is not correct.** OP Stack transactions are never reorganized in response to any Fault Proof challenge. +Another misconception related to the belief that [finalization takes 7 days](#misconception-transactions-take-7-days-to-finalize) is that **Fault Proof challenges** created in response to withdrawals in the Standard Bridge can reorganize the OP Stack chain. **This is incorrect.** OP Stack transactions are not reorganized in response to Fault Proof challenge. -The Standard Bridge is a bridge application that is included by default with any OP Stack chain and connects the chain to its "parent" blockchain (usually Ethereum). The Standard Bridge takes advantage of the special relationship between a Rollup and its parent blockchain to be able to provide a high level of security for any ETH and ERC-20 tokens moved through the bridge. +The [Standard Bridge](/builders/app-developers/bridging/standard-bridge) is a bridge application that is included by default with any OP Stack chain and connects the chain to its "parent" blockchain (usually Ethereum). It offers a high level of security for ETH and ERC-20 tokens moved through the bridge. -Users that want to send ETH or ERC-20 tokens from the OP Stack chain to Ethereum through the Standard Bridge must first *burn* these ETH or ERC-20 tokens on the OP Stack chain. The user can then create a **withdrawal claim** on Ethereum that *claims* that they have indeed burned these tokens on the OP Stack chain. +When using the Standard Bridge, users who send ETH or ERC-20 tokens to Ethereum must first burn those tokens on the OP Stack chain and then create a **withdrawal claim** on Ethereum. -Since the Standard Bridge is a smart contract on Ethereum and smart contracts can't run a whole node for an OP Stack chain, it has no way to immediately determine if a given withdrawal claim actually corresponds to real tokens being burned on the OP Stack chain. Instead, the Standard Bridge delays a claim by 7 days to allow time for the OP Stack Fault Proof system to filter out any "bad" withdrawal claims. - -Anyone can make any sort of withdrawal claim at any time because the bridge has no way to immediately distinguish a good claim from a bad one. Challenges simply remove a bad withdrawal claim without any other impact to the Standard Bridge or the underlying OP Stack chain. +Because the Standard Bridge cannot immediately verify withdrawal claims, it delays the claim by 7 days to allow the OP Stack Fault Proof system to filter out any invalid claims. Challenges only remove bad claims without affecting the Standard Bridge or the OP Stack chain. TODO: It'd be really fun to have a button that (for the bond cost of 0.08 ETH) creates a bad withdrawal claim for all of the ETH in the bridge. Users would be able to see first hand how their claim gets deleted and nothing else happens. -### Misconception: the Sequencer can always reorg the chain - -Sequencers play an important role in an OP Stack chain. The Sequencer acts as the block producer for the chain and quickly creates blocks as it receives user transactions. Here we'll address the common misconception that the Sequencer can cause reorganizations of the OP Stack chain over long periods of time. - -The OP Stack expects the Sequencer to produce a block every 1 or 2 seconds depending on the configuration of the chain. Since this 1 or 2 second block time is less than Ethereum's 12 second block time, there will always be some time before a Sequencer's block can be published to Ethereum. - -Sequencers **can** reorganize blocks *before* they are published to Ethereum, which is why OP Stack chain nodes consider these blocks to be **"unsafe"**. Although "unsafe" blocks are typically not reorganized, it is important for applications to understand that a reorganization is always possible. Reorgs of "unsafe" blocks *have* previously occurred during temporary Sequencer outages. - -Reorganization becomes significantly more difficult once the Sequencer publishes block data to Ethereum. At this point, the Sequencer would have to *intentionally* cause a reorg of Ethereum itself. Given the difficulty required to trigger such a reorg, OP Stack nodes are programmed to consider transactions to be **"safe"** when this condition is reached. - -Once block data for the OP Stack chain is included in a finalized Ethereum block, the Sequencer **cannot** cause a reorganization of the OP Stack chain without violating finality in Ethereum itself. Applications built on top of Ethereum typically operate under the assumption that such a violation is not possible. - -In summary: - -* The Sequencer **can** cause a reorganization of **"unsafe"** blocks that have not yet been published to Ethereum (within ~5-10 minutes). -* The Sequencer **could** cause a reorgnization of **"safe** blocks that have been published to Ethereum but not yet included in a finalized Ethereum block (within ~15-30 minutes). To do this, the Sequencer would need to be able to intentionally cause a reorganization of Ethereum itself. -* The Sequencer **cannot** cause a reorganizaton of **"finalized"** blocks that have been included in a finalized Ethereum block (after ~15-30 minutes) without violating Ethereum's finality guarantees. +### The Sequencer can always reorg the chain -### Misconception: Ethereum reorgs will cause reorgs on the OP Stack chain +A common misconception is that the Sequencer can trigger reorganizations of the OP Stack chain at any time. However, while the Sequencer can reorganize **"unsafe"** blocks (not yet published to Ethereum), reorganizations become more challenging once blocks are **"safe"** or **"finalized."** -When we touched on the misconception that the [Sequencer can always reorganize the chain](#misconception-the-sequencer-can-always-reorganize-the-chain) above we noted that transactions that are **"unsafe"** or **"safe"** could be impacted by reorganizations of Ethereum itself. Although it's unlikely for the Sequencer to be able to affect such a reorganization intentionally, Ethereum reorganizations *do* occur from time to time. +* **Unsafe blocks:** The Sequencer can reorganize these blocks (typically within \~5–10 minutes). +* **Safe blocks:** The Sequencer would need to trigger a reorg on Ethereum itself, which is complex and unlikely. +* **Finalized blocks:** Once blocks are included in a finalized Ethereum block (typically after \~15–30 minutes), the Sequencer cannot reorganize them without compromising Ethereum's finality guarantees. -When a reorganization occurs on Ethereum, assuming that the Sequencer is not intentionally triggering this reorg, the OP Stack chain will attempt to gracefully recover. OP Stack nodes will automatically downgrade **"safe"** transactions back into **"unsafe"** transactions if necessary. At the same time, the Sequencer will begin the process of publishing transaction data again to re-establish the original chain. +### Ethereum reorgs cause OP Stack chain reorgs -Graceful handling of Ethereum reorgs means that an OP Stack chain will typically recover without experiencing any sort of reorganization itself. In rare cases, extreme Ethereum network conditions *could* cause reorganizations of an OP Stack chain, but **"finalized"** OP Stack chain transactions can **never** be reorganized. +If Ethereum experiences a reorg, OP Stack chains will attempt a graceful recovery. OP Stack nodes will downgrade **"safe"** transactions to **"unsafe"** if needed, while the Sequencer republishes transaction data to maintain chain continuity. Although extreme Ethereum network conditions could potentially affect the OP Stack chain, **"finalized"** OP Stack transactions are protected from reorgs. ## Conclusion -Transaction finality in the OP Stack is a lot simpler than it seems. OP Stack chains utilize Ethereum for consensus and inherit Ethereum's finality guarantees as a result. Once your node reports an OP Stack chain transaction as **"finalized"**, it can't be reversed. +Transaction finality on the OP Stack is simpler than it may seem. OP Stack chains inherit Ethereum's finality guarantees, so once a transaction is **"finalized,"** it cannot be reversed. diff --git a/words.txt b/words.txt index 376553b4f..5be79af1c 100644 --- a/words.txt +++ b/words.txt @@ -1,5 +1,5 @@ -accountqueue ACCOUNTQUEUE +accountqueue ACCOUNTSLOTS accountslots ADDI @@ -29,8 +29,8 @@ BLOBPOOL blobpool blobspace blockhash -BLOCKLOGS blocklists +BLOCKLOGS blocklogs BLOCKPROFILERATE blockprofilerate @@ -326,7 +326,9 @@ safedb Schnorr secp SELFDESTRUCT +SEPOLIA Sepolia +sepolia seqnr SEQUENCERHTTP sequencerhttp @@ -390,6 +392,7 @@ VHOSTS vhosts Viem viem +Viem's VMDEBUG vmdebug VMODULE @@ -403,4 +406,4 @@ xtensibility ZKPs ZKVM Zora -zora \ No newline at end of file +zora From 4c88d3a485e8e0c9aad4d99dd3ea9e86521d2c91 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 6 Nov 2024 14:15:28 +0100 Subject: [PATCH 44/53] replaced image with a mermaid diagram --- .../transactions/transaction-finality.mdx | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 2ffbc8c6a..02dbee8e3 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -30,8 +30,28 @@ Transactions on OP Stack chains go through the following process to reach finali TODO: Fix this so it has the right numbers -Transaction Finality Diagram. +```mermaid +sequenceDiagram + participant User + participant Network + participant Sequencer + participant Ethereum + + User->>Network: Submit transaction + Network->>Sequencer: Forward transaction + Sequencer->>Sequencer: Include transaction in block + Sequencer->>Network: Distribute block over P2P network + Note right of Sequencer: Transaction status: "unsafe"
(block data not yet posted to Ethereum)
~a few seconds + + Sequencer->>Ethereum: Publish block data (as blob data
or calldata) + Note right of Ethereum: Transaction status: "safe"
(included in Ethereum block)
~5–10 minutes + + Ethereum->>Ethereum: Finalize block (~65 blocks or ~13 mins) + Note right of Ethereum: Transaction status: "finalized"
~13 minutes (may vary) + + +``` ## Common misconceptions ### Transactions take 7 days to finalize From 241c58733667574797b7f2f934a0bede0c629e35 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 6 Nov 2024 14:19:53 +0100 Subject: [PATCH 45/53] update meta.json --- pages/stack/transactions/_meta.json | 1 + 1 file changed, 1 insertion(+) diff --git a/pages/stack/transactions/_meta.json b/pages/stack/transactions/_meta.json index 25cae38ce..ebc6603e2 100644 --- a/pages/stack/transactions/_meta.json +++ b/pages/stack/transactions/_meta.json @@ -1,6 +1,7 @@ { "fees": "Transaction fees", "transaction-flow": "Transaction flow", + "transaction-finality" : "Transaction finality", "deposit-flow": "Deposit flow", "withdrawal-flow": "Withdrawal flow", "forced-transaction": "Forced transaction", From c8c3d52fc14f7d74701bdd8f0bf77c082b70b26e Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Wed, 6 Nov 2024 16:29:01 +0100 Subject: [PATCH 46/53] updated meta.json --- pages/stack/transactions.mdx | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/pages/stack/transactions.mdx b/pages/stack/transactions.mdx index 42bfac5a8..4f82dfc0f 100644 --- a/pages/stack/transactions.mdx +++ b/pages/stack/transactions.mdx @@ -11,17 +11,21 @@ import { Card, Cards } from 'nextra/components' Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Transactions, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. - - - + + + + + + + + - From 76396dfd29cfc0df39252bbbf913bf1415c4d8bd Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 7 Nov 2024 12:07:21 +0100 Subject: [PATCH 47/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: smartcontracts --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 02dbee8e3..d90b6ccfd 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -25,7 +25,7 @@ Transactions on OP Stack chains go through the following process to reach finali 1. A user submits a transaction to the network, which forwards it to the Sequencer. 2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**. A technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes only a few seconds. -3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is **"safe"**. This step usually takes 5–10 minutes. +3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes. 4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 65 Ethereum blocks, or approximately 13 minutes, but may take longer under certain network conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). TODO: Fix this so it has the right numbers From 47ad29d63ee48539d3475a5bce7d0ff91aaff7ee Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 7 Nov 2024 12:07:31 +0100 Subject: [PATCH 48/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: smartcontracts --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index d90b6ccfd..84594382a 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -58,7 +58,7 @@ sequenceDiagram A common misconception is that transactions on OP Stack chains take 7 days to finalize. **This is incorrect.** Transactions on OP Stack chains become finalized when their data is included in a finalized Ethereum block, typically around 20–30 minutes after submission. To reorg a finalized OP Stack chain transaction, a reorg of the corresponding Ethereum block would be required. -This misconception often arises due to the OP Stack's Standard Bridge, which includes a 7-day delay on *withdrawals* of ETH and ERC-20 tokens. Withdrawing tokens from an OP Stack chain to Ethereum using the Standard Bridge requires a minimum 7-day wait. This delay affects only withdrawals and does not impact transaction finality on the OP Stack chain. +This misconception often arises due to the OP Stack's Standard Bridge, which includes a 7-day delay on *withdrawals* of ETH and ERC-20 tokens. Withdrawing tokens from an OP Stack chain to Ethereum using the Standard Bridge requires a minimum 7-day wait. This delay affects only withdrawals through the Standard Bridge and does not impact transaction finality on the OP Stack chain. ### Challenges in the Standard Bridge can cause a chain reorg From 71774a72b0dea78757181e48a212f1b56276c5da Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 7 Nov 2024 12:07:39 +0100 Subject: [PATCH 49/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: smartcontracts --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 84594382a..46ea62aeb 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -62,7 +62,7 @@ This misconception often arises due to the OP Stack's Standard Bridge, which inc ### Challenges in the Standard Bridge can cause a chain reorg -Another misconception related to the belief that [finalization takes 7 days](#misconception-transactions-take-7-days-to-finalize) is that **Fault Proof challenges** created in response to withdrawals in the Standard Bridge can reorganize the OP Stack chain. **This is incorrect.** OP Stack transactions are not reorganized in response to Fault Proof challenge. +Another misconception related to the belief that [finalization takes 7 days](#misconception-transactions-take-7-days-to-finalize) is that **Fault Proof challenges** created in response to withdrawals in the Standard Bridge can reorganize the OP Stack chain. **This is incorrect.** OP Stack transactions are not reorganized in response to Fault Proof challenges. The [Standard Bridge](/builders/app-developers/bridging/standard-bridge) is a bridge application that is included by default with any OP Stack chain and connects the chain to its "parent" blockchain (usually Ethereum). It offers a high level of security for ETH and ERC-20 tokens moved through the bridge. From 816ac381029f06c99e77b1c7bbf8c338d4e480d8 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 7 Nov 2024 12:07:55 +0100 Subject: [PATCH 50/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: smartcontracts --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 46ea62aeb..a2af7d20b 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -74,7 +74,7 @@ TODO: It'd be really fun to have a button that (for the bond cost of 0.08 ETH) c ### The Sequencer can always reorg the chain -A common misconception is that the Sequencer can trigger reorganizations of the OP Stack chain at any time. However, while the Sequencer can reorganize **"unsafe"** blocks (not yet published to Ethereum), reorganizations become more challenging once blocks are **"safe"** or **"finalized."** +A common misconception is that the Sequencer can trigger reorganizations of the OP Stack chain at any time. However, while the Sequencer can reorganize **"unsafe"** blocks (not yet published to Ethereum), reorganizations become more challenging once blocks are **"safe"** and become effectively impossible once blocks are **"finalized."** * **Unsafe blocks:** The Sequencer can reorganize these blocks (typically within \~5–10 minutes). * **Safe blocks:** The Sequencer would need to trigger a reorg on Ethereum itself, which is complex and unlikely. From 45a324857947d6eff9be1658139b87ea5d2a40d3 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 7 Nov 2024 12:08:32 +0100 Subject: [PATCH 51/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: smartcontracts --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index a2af7d20b..ebeeb9433 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -24,7 +24,7 @@ OP Stack chains in the standard configuration are Rollups that use Ethereum's co Transactions on OP Stack chains go through the following process to reach finality: 1. A user submits a transaction to the network, which forwards it to the Sequencer. -2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**. A technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes only a few seconds. +2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**, a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes only a few seconds. 3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes. 4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 65 Ethereum blocks, or approximately 13 minutes, but may take longer under certain network conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). From 1186141503a583385f8d03ffde39d97aba3f73c3 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 7 Nov 2024 15:54:07 +0100 Subject: [PATCH 52/53] remove todo --- pages/stack/transactions/transaction-finality.mdx | 4 ---- 1 file changed, 4 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index ebeeb9433..3aee2cfc2 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -28,8 +28,6 @@ Transactions on OP Stack chains go through the following process to reach finali 3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes. 4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 65 Ethereum blocks, or approximately 13 minutes, but may take longer under certain network conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). -TODO: Fix this so it has the right numbers - ```mermaid sequenceDiagram @@ -70,8 +68,6 @@ When using the Standard Bridge, users who send ETH or ERC-20 tokens to Ethereum Because the Standard Bridge cannot immediately verify withdrawal claims, it delays the claim by 7 days to allow the OP Stack Fault Proof system to filter out any invalid claims. Challenges only remove bad claims without affecting the Standard Bridge or the OP Stack chain. -TODO: It'd be really fun to have a button that (for the bond cost of 0.08 ETH) creates a bad withdrawal claim for all of the ETH in the bridge. Users would be able to see first hand how their claim gets deleted and nothing else happens. - ### The Sequencer can always reorg the chain A common misconception is that the Sequencer can trigger reorganizations of the OP Stack chain at any time. However, while the Sequencer can reorganize **"unsafe"** blocks (not yet published to Ethereum), reorganizations become more challenging once blocks are **"safe"** and become effectively impossible once blocks are **"finalized."** From 4460b899d17308636c56deaf23706c5e89f9f404 Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Fri, 8 Nov 2024 14:02:30 +0100 Subject: [PATCH 53/53] Update pages/stack/transactions/transaction-finality.mdx Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> --- pages/stack/transactions/transaction-finality.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 3aee2cfc2..5dd7d7528 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -24,9 +24,9 @@ OP Stack chains in the standard configuration are Rollups that use Ethereum's co Transactions on OP Stack chains go through the following process to reach finality: 1. A user submits a transaction to the network, which forwards it to the Sequencer. -2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**, a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes only a few seconds. -3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes. -4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 65 Ethereum blocks, or approximately 13 minutes, but may take longer under certain network conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). +2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**, a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes a few seconds from transaction submission. +3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes from transaction submission. +4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 2 epochs (approximately 12.8 minutes from transaction submission) under normal network conditions, but may take longer during adverse conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). ```mermaid