From 9ac53807b869ed9234f4049289a2fe4da8eef7cb Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 29 Mar 2022 11:53:38 +0100 Subject: [PATCH 01/31] initial commit: network landing pg & net addr page --- development-notes.md | 75 +++++++++ .../cons_client_net_layer.png | Bin 0 -> 14128 bytes .../networking-layer/exe_client_net_layer.png | Bin 0 -> 18760 bytes .../exe_cons_client_net_layer.png | Bin 0 -> 7492 bytes .../developers/docs/networking-layer/index.md | 152 ++++++++++++++++++ .../network-addresses/network-addresses.md | 11 ++ 6 files changed, 238 insertions(+) create mode 100644 development-notes.md create mode 100644 src/content/developers/docs/networking-layer/cons_client_net_layer.png create mode 100644 src/content/developers/docs/networking-layer/exe_client_net_layer.png create mode 100644 src/content/developers/docs/networking-layer/exe_cons_client_net_layer.png create mode 100644 src/content/developers/docs/networking-layer/index.md create mode 100644 src/content/developers/docs/networking-layer/network-addresses/network-addresses.md diff --git a/development-notes.md b/development-notes.md new file mode 100644 index 00000000000..1d80e3d8b3d --- /dev/null +++ b/development-notes.md @@ -0,0 +1,75 @@ +To add a new page to ethereum.org: + +If the new page needs a new directory, create it and also create a landing page named index.md +Then create a subdir for the specific page, inside create the content file index.md. + +e.g. new dir in /developer/docs/ + +``` +developers +| +|---- docs + | + |----data-structures + | + |----index.md + |----rlp + | + |----index.md + +``` + +`data-structures/index.md` is a landing page with links to the content in its subdirectories but usually containing some introductory information about the topic. +The specific content about (e.g.) rlp serialization goes in `/data-structures/rlp/index.md`. + +Then this page needs to be made visible in the top menu and sidebar menu. This requires additions to four files. + +1. /src/data/developers-docs-links.yaml + +This file includes links that are used to automatically update links to translated pages. Copy the syntax from other pages, nesting where appropriate + +e.g. + +```yaml + +--- +- id: docs-nav-data-structures + to: /developers/docs/data-structures/ + description: docs-nav-data-structures-description + items: + - id: docs-nav-data-structures-rlp + to: /developers/docs/data-structures/rlp/ +``` + +2. src/intl/en/page-developers-docs.json + +This adds info necessary for including the pages in menus. Copy syntax from othe rpages and add for new page. +e.g. + +```yaml +... + "docs-nav-data-structures": "Data structures", + "docs-nav-data-structures-description": "Explanation of the data structures used across the Ethereum stack", + "docs-nav-data-structures-rlp": "Recursive-length prefix (RLP)", + +``` + +3. src/intl/en/page-developers-index.json + +```yaml + +``` + +4. src/pages/developers/index.js + Adds link to the developers landing page + +```yaml + +--- + + + +

+ +

+``` diff --git a/src/content/developers/docs/networking-layer/cons_client_net_layer.png b/src/content/developers/docs/networking-layer/cons_client_net_layer.png new file mode 100644 index 0000000000000000000000000000000000000000..ca461b3182324d6e359e5776117cf483b176f19d GIT binary patch literal 14128 zcmZAeby!s2_XZ3PQhrF4mWBbOySo`u=|*Ab5|l0hrE^BQyM`J{8l`4PX@*o8 zBJ1xFWYkeY&x=7v9jl3$he;&Qjf{?sg`qZ=sRn~r7fI*Bq6(Gg zmTHg)15qa9jj-|5K3Zy1d8=;!vWh)o3;*Md`Y46|i>0oa?&jt>c0>CiZuwN8pO2ac z)O*-n<&9D@$wxPD>1FtbJ1mqQ;j}4D6dBW3CJata$IAfoMr3YHvG93oe!f!cG>xkj zxdlAem7h!Q)ob{Ya}<(a`Ro1*AwMA2t9L|ZS$VuMU`4YkR|X^eGDZ^k&<()U4ZRxK-HXb3`~$bx}jzXm0x?6+u{s}=@yuA?tl^@$A zGc3YP4=;&No-(##90<6Y&v*F8Z+(yv?3twPPEK&hI`B}GR={cw9CE%h!9wtSvOm1c zi+TfWDTIzR8FMN};XtZMN4_gj zcIUYbhU-SCFwE?M8@6fmFdJCA0CsI~{cXJf@R#VhDv-hkP>#5k8({y$7{Y?u@TtLz zax_~)MDpFRf9bwNwK`}|whO#1#yQtyS^e%JmQVQW87~GP;;GYhYK)>m=DvKB%cI6+ z`0v#6)&+8`HmM2d5m@+k(smWb6D?nsb&-Zf)+)pQ=9Y$2b$lP=d9tB*1 zCZeJ21bojYrOBZy{VFb7{c}rd^wLrk^;V)j6(bmjE#h$ad)V2KY|X zld~=hcw4AC5UewluQ>o*Z*$OrT!q^I0WU%W3a(;+Id5MguW)u4u6>;;Q)ON-Lfq>! zihh8PekpqgjHuDSsgBm#5F=n|B`blbd0Gx2u!xIvx`v#{Ojxw)JelvALU3;E3HE#(E zvU29mE-ws~$vr$OF!W#|xVO@vY8Lh?A&6l53kB!~500Jus)(6GLu7*M_V!t(Mp^(R zE6bum>i%ubr;PpWd)hj!vA?B85-2RQKLv(@uT_~}Cvkr}KZL=-<9lE1+EoQVinoS5 zKHTFb&<3Jwnndh#QomIxt)L8e!y)6$N$no~2qN;j%dcfH>k+qkR#OQMaZ9A zzz*meV#zYbY48@fS-Z) z7apNBX(HAPir#Eot3kTkMdGQD4Z>gX1gN|>f?AE4s^oC%K8Cz0UFBM~AL9&>exHAD z?YvaJnNe*5dvZyX7JFuKp=x#>&Ld*cVR*CWTwSjqAoLs-CPEd2BHFNdD}clm*%{M8 zB*@?P>3`>vZK#Whfk_;p1W!_+MOny)IzkwCyZ5u8=G1h{sm5> zH6@jtsJvJViDgS@c7At+xjSDbFwqDrU-XwWGJn?~Ol`6|aFkD=QqSYS#Og#QP@}vG zqm;TEHVc-+BqFAAY~cQ2Wxic;nzxYH=3@YLnUimw-$QoK3D!I+Z+p__Ahr`XM;5eO zZ;!aInMo(Cnq(5`OIyvQ3@8%2HTTuJ=QXxi>7j(8_8h(~K+S6%S0|K3C8#;VY2@wI zAP7=hpGdIUvBm_FF>d>1j)!#C+m>PaBN8x6CNROWyEYjPc`n9FzzU*pDZ1X;JG&f! zb_j)Ja8mimvY=RQ_9vM^LwAynd>XL}n`Tp$7nWo58Z|CpV;4l3@N$JB9Q&cyf$?Od2ixF^F`Gms4){?~Efno+&g0RN$`zT@Z19tFse_%5aMrO6S7F|pzwNZ;`e{DD$qKw;q+nGe zK@0y?>qEJg^gr*jLtyh8;_8OYK6M$x{V(kdGr|FlIg-^F)g#-p9|J5N46i|l>3>YkYkUQ zNd^w^y>*2jM(mm&NA|sSSvL>mWh1xTgdyvzLWJbOK9<6p*XHC zBH!SQ=XeL>^v4gcVBlkp_?1*f;2|bepa_5U0_qz7QUy{$@dR-^brRV2exhh&bk1fR zSe#ABf;rBD4-bPyF>oScp2C^JU<{m0=%F%&?YAKKvILsNON#C)Nvc1#wK}0PPtz7r?<_jJ{zySrUE-s%r1y~UB&g6>j;RkQ7$h&hFqN|*q+l< zaG-?64?UZ|-5tc+ZyR59CEQWfEPHl^Tvcb@WtFS?AnKhygW(E>@K(N}6Sbt2JYs5A zuL>|0AY+d1VGGR3jr2$hXU%i8W!o~okmbGxw_lFe?~)+cBr9zb41#`h``j*NiW}ZP zmA@2>Hgit#)+ngaDS&wW#e+jhzrw6mkSb5%c{-I1(tuwfq+o0l7G!`8;6?_mp(-Ji z9znXYykU|-j8cCREYe#3pOm!K!kP^EkSBuHCqq@fNoX=ZaNGIwQ*=@ne8CFYc;E^@ z`Iq%6Ik!JQ@!!)ih<1`QOShl(*1=8R64{ka0x^QGe7HMP7kPi^EPv^|Zdo($$ii~# zB(}9tpK?K$bHyp0QQ>DuTW7-|; zt!S4XA;lhM9kAk7=94RIR9J!ngqsHgA2!_B>BxiFO>!UHePW#C7%;w+6mQ=n#0*#$ zbfsV9pa6#h-zNM07EzVI)c8!B{`vCJdctrWq0{A*; zUsd0Tba;(b?a0i0%yNASFr|=17#`f}je&*Tc({lFVlTMNyv!}+FNbA(xK$sqY=Hp; zsg4a}=ZqxW8+UOU6kj1m27(mC#2%4a3oAGoRo=t(m9j&Ks>)E-uziaDsty0meM%aE zE6QqYKc|Y}qvY zA0U3@;}mhjH(GtXeoPuTqbi9~$t=B(({7B2E$)jwT-|FVL}z>ZdN*yG-mmLsQ;eQRtL`@%w;P|9EU^w@`OS@XzZ{RD~bzS?!;*T;hTQ_hJ=7||(vJuWLQtdg!QzdfF|DeffCRtYb zcn5pPFz6WG)}Qg4+%`OEUfTH@G}FBu=tky#PbjW$(O&0Jvqro4sGGYN`~l8iy5HH0`W1I< zFj#JU8?TCKKr2s~aTu-J1shQbYKco`#fIMMT~;RZeY{JM*jM4$ zCh{Wg;;@uasGWVI78zKXG|t8PWG0XEw7RO^q7lv%qmsH_6h5OXEKCQZIyGipC56nC(Ps#rx_7KWY5^?C^GtbAPU#&|MsIi_ zgODP~-gCWK48rkINL1eictpH8zr9g1# zJtz7oiqZ1+mWJ3* z;OO55XX3IEdA(lSp51e=g2@L55tn|?Kd<-r}+n-%uORSA;5q+*F zvrN*}`_YmsA?Ko%);#8C4l;~duy+T^?)blG&#~W%@am(7Gj;mX*k@#jY3x=GuN9}3 zIDe_WdxC#Xmf?qzbo~Aeu{;J)QM$7O6nq}Im!huX*A)a+8u077h+`v>TJ;}DLb|W` zqfc=6PN`ndjjvxs(s{rcYZAC8OY}$$$It&dnczRErvSeD^&EvHE!~=_JP730C$*9b zEd5(arbixP9+R+yDSBEvE|p}Yy%smsXSh$SpTP2n`;~x|7K54B6EpwhlN8>s7k-32 zGN;iZbrI*n7+Xodn|pY{3WWL8$SpZNh;*pa$%X@EF>QC7dobjJ8dd9aBy*r@%mUD+KDi6_V<>kM_7{?4Tq_{%@lE)HtXkni2CLLkX2!Ce*LxRyK}0ji^e?Ho1M zo4|WdNz{66F`!dN@8E z2*@t*Jp|bIGvBH&LNx_E*76(pX(9N{Or$?qkK_(^kLSc-;Nh@L zzXgQ)mx91uIN0n{@lo;`V@CerrXr+5lStDn@Q$S!x)j&oGWQj@dJ6^rK?1KCHBS&@ ziegCCg}}lSks00$;Cj%c<#r^N07oiWa}rQ>jRqu203O#4z3FbuW zWwll+t-;1ySbj6)PSxSp<&~Ls!bbk0*}8_~ca)$>!T_}a-V;--kDEm=RU%4=JsE`9 zrm6};J@kl`nI)Au<2J&(|0=cXfVinCJd-o(<@c_ZWl#e1AB#UpujX< z`^T7S0wJ8TQ&$^i<}+bUw}u?W$QHiImx_mVLemH2RRHj6kHdDfwMce+v>=;S`m^9? zP2>0RGOZ67wFF_~0KkID98Z+!PbK^0?BB7043bypZ`g(n!Ls|ocO;e*0}t0#H!PI- zm%R-(lARDS0AD7P4i;WI;uZ&AJNXAoHk#42S9WPvm+st`P z_)Wee=ps*Q*#gyMLN}B51}^+?^)PkbvCjRl1NqXsd^05pVCjwv`s0OTb3A1tHhQ@$ z8idQ3ZikN|C|Zu_<$kfQc=@j8Nz%p7T~}xGBdYC%6kfC0*|C6bH(vbpu2!q>e``GW z_MW_Yo}LrD3l|p02em?+%*^TNkl(f*EN|8H)wd zd(uy^kfV_XI4@!RZ6Q5hI~@{#NA46jz`{XnVg#w><9bSs*zlgy>CL0D|K4;AG;5ap zgu5ZWL}b{l?gnjyYy4IaSlOZQcIu7w1&xUST|>5cIvDAj&kgEWo5Qp?kkI!5U)VM# zCtZwEicvx}&6=F&Zg_}6C*(@y#QaLW^D}N-b)rczc0pM{P+p4zaXVBP#vG+HrCwYapCl5W*PuE}EM!dt-AX{uVsiIq5 zd(kQ{4FM`v^V=pCahs#)AEi`pNfbjZVAlRp6`ChOd#@!8(B`7rpCYMR#JYT(Wd8O? zg>n6bq&~4#NuJzge_lJRJ|1{o1H>8KOH={5tVYF&zE_`y1q6l>J*cxEB98o_-^E^h zA~$N;A$o%WC!B+2z ze``{3zQ3kOM>kZyGMi#_Q1gCk?H5?!VSAD+HQ~_+ZoeZ&9gEl94~^YQ24U))`j&XQ z)?B$=dGzsXn<=VXenT>+xM~o^>j%T157?^-82FPRnboKeb}@JOC#MqP?0M8_nxzV? zj51k1nUDis`LWfw&+Y=fh51MsgWE=2QN(d2JellGF{uzLo<-(yVwfgNNo8SEcna-o9Rg);`4Z14bq?m~mauVMSe9C_?w&id;)a42omkhh~p&kJmp+o!fe zWt|9h338KRv+s=6^Ic4E9-KR+(zY6t)HUL|$|OVc2~rc@jl@y0wj4}5c1)C#UfDQV z=iYY3IXD2+T~kv|(wgU>Hdud|GGe;o-*LV-X%gTuE>zs>9SMVzMpkOj)4xZnJ@9Y6 zYl)SpE*?CxQ2}pTDToA)36?RHc;&=-i#3VtljK6*f#o87Q9cpgbJ;LCao?bQuw)xtwLn=s1UQmm#tQT$IIL$tc%L*2=%nHWjE02 zecucC{b6cRv6Yz{n_uY=FT9$oxTX65&hSUK8>;E?wD`{5fi>xQf?Zll#(qCdZVlxM zW4h^1SS>(T+KsLY0kTe z>MED*JmLrSH5OqEx1)$dfplxY+n*!R(8;r`KUjadY;Qzx-(D?loKHqi;Z|x$;@r+G zKB>#(XDPazwzAEI1!)Aev3%lb5R74aFs$$NOkR#upuT<%-b`MuM&STR!7 zTU?4D0Imh0u~%+}8d~a?fFS^%+cL1|n+)<~O0<_^TB3p~G)RE-3<>+y=SGRsAYJ&?-LWGLxyWMt9{AAz4T`t&% zX83m;vf87iDL%gR`wzalzdkogZg(Veb>fUm)vDy9B0}H&Vm6B?e?Ka8f3Q~R6hwRw zseXI1S8KkSdsQ9wfqwUvHd)s6}dr-rr7CQKtJAL@W@>GZfX?sfNd4G#3QPSD1?t3^cPNF06d@TzQ*&^t@{jIglqkVuCkNBhzC9q8TArMuG4Ne60f?JJieW$ss$%7={u}uq>=Hs?EOZ zkkUhPjV#?|@&jZdBzWP6U1K9BclBIZQXt1$G6od=>9*MKmPdztdyzv>Fb(H`&Ksn* z*W3NP{sW&N@5s*vhO>KAdVxhr25(J%{^BG~+6lSpJEhws6mlBrNYT+Kq?w#AN(b}q z?wcAc1=}~@0%7pRmCos%FZl+qO=51moVK~WoD8bK?s^^R(I8Y!NNz}8NG-c9;{YcU zirCO_rhD8EOT29I#dVg#C`k}VR?}AquxQOwxdd>>z z*F9Ag0vPzu410#(p}f47OZgo_ruOyh>})fP43Mvz(9X8=1OOYJUsy=3CNV{H4~V7= zFO-(Vxn99Gr>cjG)6%%1UZYO698@!|t_?MJXD5+y3(dBfcJ~_{hFd$cW~A1%Z`{g?=dbhPJ!koSV_2xCs;-a{RjibPqGe?6*Yt3nROwl#fQ5;imW&a7FL;ee ze=R4Di4pgoIkVv{O+(ciN~jzb*=g-bbldrj%8ddRJfz1I$+f5_5f2+7OSa#gY~@kq zZXk^u;&Qn*=9C$p7`y}CwoSMOE>Y1qOlOMCM8C~{LpoKH_lBR};6ZN0Z_g#1kr^x&K}o;D1Z?#a2v~CjTt!)k1AaE~jl2?>g_``@VF1Vt>zcZN0Yl-X2h+@I|{C=66DlLAv z@qB>t&m0SI9WIlB(^_2JFN3tsd8mhnn@`%ix2ezatEE`91jUUE*7_?uC2_VnXO#Z{ zQa_`hBBQ0HB}3Y7da_mp2nf4g_1%8aF&veY(S1<^Z2_M0m6E9rnhco?%8has-S~@Z zFjXz9t8;3Lv)R*zduUOzuqRj_pp>JzuD@t7Y;vL`UmHycP3un07|nfF{AW>$ipz4U zT8pn0X??Bc!3Cu?tkJ9+chNgo+)Z((%O=Pn!xp424M8!5vz+AKk27eA>f8@{DxW(7TnqoE03t~NXvx3|E+h>N&A}5w}i8_wMrup!>~=6E5V`V zL)Ac!i^0iBT+hS)r(dOSBAHaZrzl`~*+)>~G)K!{46!Y(%gf64Jaf)8rD_kV89eiJ z-=lsoNm7)lUCxH2wl9y{up)&$?Np*k+2Mg6MM((tK1h(K{iXTBS=eV3lTIqoN;NnD z-dz^Wa=Rlv+G*_R+QlQpT9^$sTa>yk1si1#IoPlqz$ER#XX!m3G<@kMC$gL72MF7- z8kn?1>M+Lw72(mWl4*+Gouyqkyt|q=cMq}`KB4=6*H^^^+B4r879%0lxxtF?wAe)9 zv5wdCuiE7eWZMHiZyHaH#4;ZVWxn2ze{a}`gn*}8m?X(nKGO`G>Sb#S1+e_&wXeWXc2lEIlqO#J`C zZ+}0*)(Aaa8tOEl4{Mr^%7xaco#!$r9>m%8YWw%)dS)rTbgGvfKHO-xWOV8&0q-+7 z#%^$6F4>B4Q}uxrpSi|^zozb1 z!hzyC+~4GG;Ib*{rZA(~(XNGqh+u!|^#*V_X|xObX^&4vp8Ex|)5?9&39;lL=Rdr1 zYY_9jfq=0+X{GEcILAFqv#ML09K2aZZ%2xSVw5m=DejPX|MBb$uheTVO-QmR5bTqA zREynna+e%u{xPYu*LzloHva~-PSsy#G_>@tecU18zqcRul~hiUt{I1Q%X2h6e`6<$ ztejBjYuQZhJ!ATTqqDqy^=e$8#k8zNU9H_BB}9-=;cLP^-8{yplnM_OF2QP>x3~a* zmKa-73el0a1bL8SJ?KPpk5UZqskQZdhg{i{Hk_uxtgMQRPx=u#3km!|ySNWkF;w)_ zOGL?(Ft_)zUgW{^VB}LO-c9M9?g5x7wz12C)#U5a>LjV~@RouM!`Nt<*9XuU>wzXx z@a9G-4q&l?Ts_)Y@f8TGwf)7kR?NPii&Khv%= zx8X1SVhS81YXOZ77}~=@d`%<^Lcu_mdd~rTtldZz%5Oz1?ksOprj z_I(WA$PiRK7pu1zJ`mq#mdJxjuMQE8#O|~k?Q!czOm8hq&FjyVTvNpG8F$8s!bc7qzQ_2 z|LEwRYIfhTF{kV<82tOe^@elDF1e}0_TrqP>&Csc%9j^WzQVk>+5T43TbuL2zOf^6 z(ahze`Y;Z&ya+R6BGKJ!XUFfNI~Hog?vBo!oSdL*)(m?Ix@JyydvvgJOW2=H_P+FX ztoX$c#1g!kqO)xQ~KDdlen6>F``;Hz%01YN$b7xVBo5SY6N(}%(m4{84;@M-kVf(aAXUqy%8CSd!U*DGIxfMY}*L?gQ=*d0g^Q{nvJ^B+TXjd60#Xpx^`D-SxAsj z$%DFe8tRZ5Fq+VygONkxL(|-rw7FvzggISB0QT? z)3EIN@xNu9Gj}EY=Xg24^ww#GXlXEGCIbfSHFO`St!CtE6{`5FymLD|1`Xstj2{#% zTFfz}Nj}mpw}Ic=IJ-hs@MBEriBPFH_g7at^qgpNrLNIW2aHddcER)pdKME!&X%Pr zkrj)FWZz}O5u@6mdj9$tDmTny`m?J|mf*kX&#LC5qjh-TIgGEa_hh4<_!3NirY%h4 zLXhiUVjzyNJ@4Nr_dElqMDK%teM(|Pps)8rFn>uhDkd4w!J!xvBY1FirCBTbXQOBb zz7m)XvoPbIYZlfW`q@S69l8_|918fqQihXIvVWz7z=AJL-gf^)Hzs2u8^mt%zic_f z(&YbTV}b840DyztC_6Nx;9u?hdqPhgFTgxo;8S>v)~t@%lT_f9A#Pu0dl)PXN*i%0 zTC#dj&5_FZ988u4^Qq+oBJ)4_{01W9!`Hq%lQ#@S4yZpw*A^uFhVZVx_$Mil4MzJ7 zh5lMxE#r~Vl;|CQl3wuPTd-JK9CdMl!Ob&NkU!MApB$RSMHm~; zwjMzyczY-UDm@P$AYG+5+S4g*s4smW^|W10W*r!|&)D-yB#}V(Ry^{Gwe+*k+<(75 zaR7t%_fd5b`$TN-?qu_V(*M4dBC4}i96#F`x}>~(FEHC6N+fj@pVc^km1gMsNG^D9 z^p?8aI#R8e{NRMRX4OqUnZzWXr?gwvKB3udaYYFn zgnn;QJtkX92Vb%wE!47ig%8O<;?W49hm8)+4Qhze#}HDs26byZx$5jqUb@PliL= z=M9x&?FzY-evL_mq){LENm(MDwEsq9flk_!Cjw|SaxfnhFjiGqM)y^QUhGww zy>#9OUL|-pWW%lFT}Wi3)*OE(*mDyS{ReDPNsn|4>2$u&HLp%xXvIU~<*dA;r3zg& zw&uBhsWW!Yih>slFS1(~uBiMGfRaCy}NScsbWvv(!KJrvM^QvV!Uw zj76gjiSnk(=-p5t^0pg6Uup8E&lm=J9INizqX~v=7XM&&7Rd(ctjl`yLc3grGI=tr zh|1I;kosC~md` zua#tA6+yA2Tk;~`=?#|4+AHT%@+DBXxPpB!G$^tRe>bi4wJyv;)_|4Xd$0G#~%2Au_yp-Uf$*lJX!e(wrZ2?-XIy~3* zY|^TTX-81csAq~^fCpbLR}ZAn}~_P)i}uSS7vUsjcGq)mH0` z_rX!=VyA~ zfzdaQ@l`FeLq@+st@RU()ujDxe`WSOH&8nv8*3(bPexO1@d!FG^9p(S8B2VSbR3(@ z7p@9|=YXCJC$dtxPGt7uXbkD9of9-45fZlDU*$J{ehR`a_Km2iqKVq z?+OQe+}9f-_7&(N*^qiv z-~bfF!-beMfrOa$^$JYQXyhc%>Mi7gs<1$<4eONxUw*ek75F@ThlVG=D;*KJkA_ zRf*yklZOxvC2xjkE!r){0RMogUNKT%(>+46twE5hiI4A(LS>I^{`Imfw-RPAfpT5G zi6d&@mTuJPPR18&Bmxa@(j7B6HfPN?{Iy{d&~{#BZlsyE|2eLT4}qogR{a29K{mz> zi|^|iT}j@jfn&T3K%7-+&tgk}A>}%dTroM%J?`eCG2rq=1_A;czGComrHGtnbZk1O z)lTNE&->S|s(^MtBJWu8lCMrZBI55>@am4w6N`f6i$OO?b}8MsK=>3DwZnn0fAw=7 zG{pb)s=bG0g$nY#`i7O*Cb;)M@A6++us@nBJydHKu3u@B688A z>E3s#>0_k_2(cz^nBfm;rxym>AGgf#Tz=H&aNGS=RE=b$N25?Eg&b) z@AlH4boup(2HW)?tON#}aHXp%DU7TX`xyhCGtyY_A7mxs@^MGrFZabA{$L)i14A_b zOR)buvQsqJnMO6|%)D9xNp!omCza_U(S(E+5a=-JDS`x)CBVwHW|lykBDG-6wd$W( zD!+te2LvS|z`ie#kv_JUyqfUAZHZe!e}P$#H6J?st@h+JjJxDF!K)sBqy^Tj|0c9X zf>;ktf~SrcSK9^tdhQI!YC|^)Rz&U` zG_z!We-Rv$4Q!-Ov+T_=cj<4-Q6sACC1dS~V(`=yp1m2nAB$x)rmz|$o7_K$E3=h;Mk4oiUp(~AqbFMqjZu&`W&#O~`Z0hbL)tdX!}XygF8%~?q2YkbIja0!Vz)1D zB2qje&W&LG#gCNmU1#Fc#iVHUEq3`D5GQC!z_yL6@tUg&Mfd3b$qKrHbWH` z*vk0Ne8pS>=^B=aE#vUK;N!Pqy!TnU5k}5`6jyG-{9JTD`rE_>U^g zC3rh-n+;6=EvkVX!Qq+UF#Z(6xW_-;qm`|N#=}$31{%VB33~MW?+T;et%332F*(D4 zIEreVX&;^GCygsnP;@olU@QPP;3a@hJsZtDqsm0ZImD`D01-k#kmVh51Pg-0WKA7oxxZFE$)M0&+(UEeD>EV{>VH)3DD<~B6Vv~A-DqO>|0jiD byOtFksqfbvuqOKVD;!8!Td79jZP@<I zPEHsY7-nZ@Wo2cTmzU?~=M4=F$H&K8T3VuGVgdsL@$vC_czF2v`RVBBG`@Z7=;+YY z)U2zkyT89DB_(ZZYa<{agg_vIf`T3%p6BQ1I5;>*M@OirsOjnHoLpR|r>BjLjmO8w zgUS2CJD|>r;#>OT;e*Cz-ysM1#(~yvmot>Sfr6pWEyz=sLc6N3P3yYeX8gg=SQZlmS z%p}8%D0p&6^wgH1gic`nf|_cOB>8V8pWwb-Vv4^nhI|GpnVPp0PqAl0ZMKAK zwI0diTdE7sz>|*k;KPXZzK;u`Hdlc#nze zfo7qOTvt_6DJwy>F6xb zR{YC&sIG>&JZ@;kVF{VBCDOq<0^u(f=y}a5nHTA;j27;%lm0Wd4q9w6DH&8*#gA|< zVf(tPPbvhi9;~So&DgE=WGlg2VeNbR(b(M}G&R#y1s1nBOBgQXVXlV{2u5Wq8M-L! zqb%{+HZU}vU!?q+5Go(LY*(>|5Yl|B@pB8I5Y&0TH|b*TYS$DEEf6_R#LKS>D4Efl zUzWmz7X)!KZ{pgC9c18!P@Rre>6 z;^%aFadFSl9~S*DF+-*B7#Q%Naby%G_^~5@83hGW_AD*^|D@(Ix=BCdWs_G5h8za@0!W z+0d-^$|h;Vb?*>4tJLL3Me;ysh%$4MEB%8cpx|sAlhygcG??q$*3dQB+x~MYib{L> zU9=iCojF8x*lu7%u=}-zGXPmO-`U)+kIba|dkz-}<7HzA4JC@aAR_v^kr_daM?;T* z&axll{?jIn^16E?+oqL}np?FF2jwX|LKg&945V+3O?Y*gugCg%c&-gg`m=i|Wf$$h zEdS*1RbQ;QU&-Pu25o7&QZc*g#;77usGYt7S+p&7{l6P2ZZJ6!^M`Vzm!UsLVrpmo zFIuRY*SwidOor1wga=b;pMNzCK~G_GoD-Ce!)4j;87*lc9ANge4RQYzCx68ErvkCB zzo&Op9@)FjyybnJ$qms!96!R@eC(*~(CRO~a#JHheQ{BGd)c&)v+q zR|p*Yx>b3+x6jFThSQg!bA$%P%-bYR4=bxD&EhfYQ!!xdSo71F^OsZ|)AJ|oHz^Xy zYIU20*Uz}7eWZ`3;wbwsKJ}XkaB6za)p6dv*G{7+yuc?gcmxt594$9--{)~YusT#vQbmR5L^m4e zK(s1F&_l7}2%&K#P`)&^8t;x?Svc_M$$W-)tu>&ufc?bu(DTAqI$y0o@Bepmr*1x4 zibXf3qn{oeuB$|4l6LMYSqs|}tu27xHG-m45wvpcLdW4ToVHEs+WKT>@m1Jz>@suPszU6YLNHU06GPT>@4b`eDEQ* z%%$!0BKOopu@Ka~FyqYL7TDktz4J8VbHB_<(`9=ZeSTV%DMXS4&t>g3cCYUFr5Gz| z3$F9D*)x^du1$-|G7e)a)32j)>iACir^jJ?T0uJrSrV)l_IV?>&F6Pp7iq?IZt#>O zUCVCZ!!0X@fHD)jVU94oJ{LB;0N6wIc^%GQKNPT zdUtHtr)kCP4o!FX%;cTL@{Q%7i_J*^5vs>KcN-qNj(=;>EJPNG)`7C;HCY*PG7m78 zz`(42DC;t|3QWX0r^3eW(|;1Gy4MIaz752`DHti|Nw%8Nu5ZKsnqu=LXQ1D90B8;g zmwvcs$c^7XyO#94p&6GDjBB#}bP&~v+b#>+klGZk-^G~6X-y3#k#&jiN)8wNw9ZaB ze`g@)167_Z==-RN^W1+kHx3JQr@cbVPw6vGyN3;>y_Ufs1~4+(BTrD$mK;|d|7MC) zvj7Bx|L)qQm^?Tan6J1h6C#Iln?dD?DHtTgmuk1dvk(;jHI$H}u9^?QZ*`Rc*}px68TvvS3&9hw^=Sy3QK>WS%sS zpDHQ#@^WA!St8C{W{PH}+hxq$S0Sa4on4Q@fB(#LYs+}|_yVx@=4JTdtW8+DyTWRU zIW{+(C6?O1C1)Ldkw8YZtB5Rn7&0zuYOQy0Hqj1z^c8%M%a*O=U`wsUc59cqUzUUn#u@Wy znn}A-my9LVh_M0o@#AITB=+;(<^i_#ig(=XoXnK3TKk$k@_|&DU1~5kg=YRJ3_l8- z?r)G~{z?$UPoD{yMQz(}80^To2ZX5i{h3_hIt;rX_Q)u9er_by=dDL!6oYT}320eA z8N~avxjfr+>;wt+4hcO5Vi4$XWvf$fRL8~8D<+j9J7{Elx%NZNAVQN;C64#4f}8cr z=a=tUaGX8%E3C?$C5XwygHY_|SW3N!GlOI!B}k$8EBZ-)Nt!-neS1~qfB@Pi0@kR5Eg@08!z z8uyQi2;<39sLlCb{Hf`|i75MD(;1|&eU|103qH>y`WiJpccgxi9|k;6yl7b>_ClZ! zfoA_2V5JLn-NqY!w7vtM4qRh^Z0fW-B{S;gB*W817}{FdIK&2$rj10jr>6{DM?9T9 zQra*{_nIb~$Y-+bH$!8J(drC-kcj|1T7*7-l18gk2(S+?CpTPkw~2i4?#Tg+Ja{N= z6lB`_=vSomc6S$`-`$JfUW|Kqpu;wwHd^D5ZUhRdFtq6`8@*fZM=u|KdR`VwN{Lrt zE7iLWIX2L+U^kN^cKMC1aGe%YdKEason#YvINA3@6}zhow>)Q&x&GaE!RFQk&SoKTeuLdr=4WGB9}3!YXYa-bJ=f8li8-(THD%g zpD?g&<$Vs^N!VXwb%YP6)RuEMM80r%D=}Gmlbv*CSavEXPw*{cu#~{p?2&z&u|mtp zy^jzA&<+)}d4)fT_g5Zw8Sp+2u?MWnwpR6EvvO1ZwPz8p{Ab|+NUa-aCcH)HSN4Ct zE9FMhWf?5ZIZ*nY-*QHBb@Yr#Y#@;C?4dv$nZbGRVh)&*&!6^Ap(VOy&vE&CQRJK5 zNzCPhrD{0x(2v_NhW~h~OB_l}X^-zIRqlTHQ@4p2k{b_XYxcVAClW&Rm$-o@D?8+N!^wkQVTf?;#}_}TKdGoUVCdXZXrI>x97^6Q6h;p|Rp9xr)bKolJ0Yn;uc zld+#sVh-nhuMH@-dA1nttd!%)E$RY?%_7B#erK0Tg=To{g7f#HvaU*dA;RDc)1pC5 z%;x4Sd1j7osm%{uwjG06m!$}vyOiO40EA;Rl-6zfuCY&VM*JT}t<8G!Uk5--b9aHsA+sq4sODZ8wpPc9 zrF&S#AA|@>WD7X5l7A=w{-WqDvpo~X(H-P9iu}c-=-D+ar#Lj@*5@?d7MYjxf?>aA zwV`D=%b!$HRujx>r*3Cu2=xkk zTafkZu^G+Rz|)H)O)QnMV35S)_<0Q-w#YAa)QUK!f^KbyQ#Ez^c}z`i60OffseF>& z+)@HDfYG_;eOC9&e7fyUI~|z0^oaDuTqML2pWGp{SI3^HL+8%Teo5(xEt8K6yiKaJhnSa8mlNGwHc9(~gGA_?SG+vtu zIp%oC*h@St4*3eX_1?cm9@G_+krF&tht+eO_D%LqOnM6ev-P%C!w$cqdCOj)DuC2h zqFHMl*ZHoILX)4U;4|?Bo;e%8pF=%Yh;?dlyubv5n@=B+vN}VDzV`8!orQ_Py-Pd; zkuqDYdN3hj1Fgjj*wubjd1UrH1My->;r(hp*{R1rXElXdc|Z&rRZg2P|ME?Z`WX>< z%MfNsFUMK|o)a;1niHH(&siaWwq{q6WD&A+(o?GBG_uT!xF-g^w)Fnc?3j`YSrYef zGv6ItP^w5t(RmMp~g3EG>o>fNrd82pa6sSE~$fsN(2eC68j9yG--N$YKkBZ-Y>+NTB~S$3R}*x{%mDX??Vh4 zI1EXnC%^ql6)pjAu#xGhyxfy(;5)T&h!6)x+n-S=G-KqAKV>&f7RWet(i_ut!mM3| z^9@iK5UE-rCO>>IRuS_i-Jg$g^A1*2VbbPqBl8HwF%q=Mc0K#yXOhIeuMLHUx$55* zr`M)8Lrd)fgzh1#8fq{^(-VVxRZ-uUyjMbnKP>wgYGN#8Ox#b{-2Hcu}o+bGZr>$I4C9M zLpB%y^OyGbrauM<6YKGjJd@$Em=iA*9wHN@?z0Q7WEb4UeMT#JPBV$}%O90xh`xO$ zEEY|4B=3x^UCBdVm#RuwQ^1voiKKBH6<~jCD8+)bpg^*xrF_yhv9Th~Vo@MeNlpqu zwEJqryRlAX(mrLBh5z)MjA=+f1!BDtmLjeeIA6acCh6~e?KaTUGj2OjT#^Tj!pXIg zZ4|dxw%56Q{ftR18x9cqQ5F>s$aDpN486)Y}1j$MSqOSqsG!M%CVby5Wd29eqNn2Q;y(BfJi<}KSv{xC>K~H)a^xNg-os9tf1FZg zAkAjhg73l+YLPx?QGW#=XoGg=L610<&r~A?ua4UudrVb4Dnz;n$9~ts_I6`i{{e*h9o_I%H!;oQ&ql82zy?# z*RMwhuUWSZ1{F00ZcYSkUQUJFzQo+$@A%D{o&Ml?r7J;6GTVt7mGKNYI2UwtAl0o8 zEPdf5G8fgwr~?@#&5`^(@urmb@Q-s^W)u&tz;71L3{vNA@Dqtpe{pngATBWA-xwiLTXOIh1$`oKE?FeqIvY<&ODCHW=e zy!#{fsz@_TP-~i!lO)~5*r>R{qI(65tB&GJ#yY-@V{nqAEc5ozJp8LY9$zlsF3ZO^afL4X3_dMN!^S7p4ov>=l;UAxU* z6MxtehJSC`WDGr+J=X5846<%owxHBQYVMQM-T+O^hfWq>NeVb^p)^FbUE0S`yhMzv zS5o&?XcNXj1e}6~4SuOd0>Fb{48nnux|A$wcwm(Ow|W1MH8}9{fBMiEos6u0ecAtP z?n4VtXdQ2s)K9+S^rq9D5D&w#HabFboP=cHKpz}LpMP1ChMvwhOs31S@W3yXa!m&= zswg^$Q7%VT|2d%RB38gUHJ&NRgzZ<`DN&wo;s;y9RPeDn!CVliN0bjEkmTYt57hP->3Fp> z0Sdc3%5i-B2m*JmtR4L~g0QID=;Qy!j1LFkQ|p6Xgu;)ewyc_=7+EqSl%Y0`rxk+{kIqG-iXNQO)Z}9{XOD98xKV4a(6>@6R z|7W>W%&I)D$bSf0;4i@11gF$#^ySk?5L`LMoMlO(wUtr6*GVpZm81X1yE&=F%{AsD z#5ffUdF(>hUo83y69T_84fV-lNu9@!3V3hbu)emje}Q$jMfxx5(5MD3xhbyNtsn6& zH&P6nA3m_(Pke0>2mE47gnGrmgW5Z1m1PmhimGCbZqCsd?UwQlz;mUhIA}IokZ(YF zS~65@m0k~IYU8QTzSMj;b(IkHc6dE!Vm(}FTK1-WgbhPXgi3J%@%@%uTpB3r>TB@b zGLIg#(MLOOk|PzDr#w}$eC=o&{9^D^K3wXg)gvyM&_*R|6&1*scHe@Rs)kt_Lo5if zy!s)z7@9;FiHSkpum3+jVdBhf4m>}F<8Zb8k7}QabtpABoc|-@hsB@0dZzfP2FCxG z`4ahF4RLUtiguyE05hNR{m$IZR(t}{EFb}bse#w@cPN4+=)QS5pfZ!i`Zax+?XBjG zXN8TV_p_7SswsB;mod1Q4Cmpv&6DFf73DvKW?E93)!H~vK*8|+53?CH z8LIbopxM$Vb~w;APG=F~^==m zXr(gHSuE?4E|<34UD+L_|LrS7Laq*1in}d(o$n2?s)IRnc4l6f#mvp@EXewMzEmX?_8rxM@!pnmS^tt-?8-TM;IM*FY%f>X$crxn&oF($V5c&B*(IESpu;S z7l6c|1g0LmDA{1kQc06_9irxW9E8CvO}82D~R9pv0VE6pmg+ zp6&cCz)cWVqAxIH1`^Wl^>ber2_ta7vm7OqgHtTdncns26*Q_T1MSHuw_38u60MZk zlYCX!jT4oU#F{_G1s!J@?PY7xFx@8k)5QD{V!_mc0s9y0cir7Tc~C&$;)5*B)-o%O zo;r(~d+gq{cMJ{@isNE0LL=(3e~KdL1RLM}$PxdB|I5w#7hyVXAIpGf?q7%;4IzKk$qImZ?uGACN1P@;uEtm94afDoO^(BvEu8H`MF>z4hoidFc zLKj}VJo~F*Hdcn$35SLe_Q>s@&Y6-x`WJ+@fFm5YMBuPSA_>U+HQV!{Sr#fks}7EA zx&kPF4uU%-q-G>hh;Bb6182a6juI8@CCLDggRXu*Ib1*X#ZM3)AutPI(2n4T2E1XE z^a68CkYz0m|I6Y!4oMZ?d*MOvMrhIl4tD`POu^!mZla$gQo~7gHo;%m51WQ1cQ-il zbL!m*T@k6fEQ&oQn;MUo_ol`Lfn5EFXDI(28GUgdKVU>jQ;UQ{w2)p z_0oUWc^uaxI06MTSl25jn=Y4am805>J-3OC4Aw*DOHh;q zLOpGm3gD}+x4aKAzXIn#@WnE&yhHttyN1#fn(?J5x@E(p!%mMD zM?AqGq@L|><^3e(=VGSvNGmo0e70-UEG*z(?4Q94RP^IK%d)@C!q!MD$e%ok@2w-@ zKrSLpnQrN|w&o_Z-x$)oYqHLX&srni$ z@L2203Z64d$osv2t5IO=d0VZYc&&YST+q?S?XFsDwP8x;pVjm~&GI=%oj9ri!qRlK zDswZ`iCa>Wq&?J+Cy{rT1vHcM_s=7+UVSx9aze$MZ*a}_T#~{S=c=&)x>wmsn{{rn z>?7mApHUwiX|*6UUP`gQ@=sdzI5ljb|FWKN=UeQ?j%7!%X2-m6&RF?4$?bZ*H9BDWV=;>a0bEjT}#FQ=OsAl5}pwYu(Ltj%c_ zOzHh++JFb~wKDcSwZ}2EdIvmUYkd&HgKQ8Nrabfoi>6GfAGm`GFN->acp|<>1;o_m zEkj~zNy5C6iulb`MOl}MG#iygJm?^sTnAW~yOFXs(Snpb#NJ~WFEa9mnx@)f;$8MW*(Z+cTG&1l)Scl+V+YvrIUTN)Vrqhs5TpYKY*uloO?Li z$=j0}hG^X^p{4Bzm}*D86lsBWlsMFVII53F3W}yx^;nm{K_o#>J?I8iH9^Pxn(l@M2i&soiMTJ_Tx~1(8&*n-p}v6xgyHZ9YnW>~(qSvhjzM7DBKPAr>Y<)EoIZ1vVH#G7 zJ4?)#1^ziZ8De+;&*zCBa!wt{Q7LpUd*+v6PE!CIVUe^thq{6wYllW?P{hKxk^dFy zz|_$fb7S#>H8|Mhu`m|vn?2Y!w~VkxU(WE1bn$}FLjtQ3wxC{AFn`})sP%-;>-9b9 zDIlTsgUka{@4@Fkdma^}HUR7PkTQ3rXQ2EJhOA=yxA0_Me81+Hexp?B&SaIZ*qjmM z7J~^es%1{b6v1dqziqPXsm7@jX5XnL@OAIRr?hr{@*5RG@PxT8A4oymm>@OH0_kNn znrot2dv+BhzRn~{Bbg2|fe+a`H5hBY+j2ts?W%yt8)w3Ao#Jb~C$we=ML6-NulGd+ zOKyjMyYC}Jo_IL{d`v!QIjyQN(T8yE+aGytq+tpUcr9g&o69IUnXBFcQG>8i85w$amPj+PX9^5b{&tvlouoxaiO z_YEFhK4L81;%s$t${Y2SNdWqbhlDqhp$Mf>>RHj;#IyBKgaLImEBooz^^$##YM!mN zcZ~9l9R{aBxp`@X6K)+r_Q+ZMr90+1F=#Bzf;rWIZ!xd)u^k8oX}}*2r7V8?ThLW{ zZf^fMaXvTlyf(p9q=YuxZ{c+h#kME)tKimHT`rtS5rCwic25Sd9;L3zkcZU0@_x>B zHIh|IF>Pt`Sf(?uf?e1h8z!zz6^a%yz#BRz3;p&{iq&$>s;kHVSHm>#h8-ts@5})l zyM{F)Xa6}-Z zEbHi)5E-ExCp;O^!rd`feRZy6{&b6X1%-6^8lml|Lm}sBs&OGib4XQr90RYlj#W>E-}8L8?mf#L zB;k$r-`t-+al^mChOt|dQEDqTL-M2wzxCJ_uPQmwzlYdVT3#B=9kabPzB_M8G(78EzYQ zKfRc8+Ul*$tQED&Y!b@jFMXYqfp&RjEKcW5MWRpSRyOBFAD- zTtIMSJQjWiMby9Dc`!a~)?7gDg$gxe>r5xo=J@lbV86YNL5QLDs##L-WA6_w-fMw9|vE@(ifS&2`MN4Dx_qs3IBB=Z831w|TZ-s*0!17!#$6 z<}I&INo(|~*_Zjt7QsR6+#;!7#FM1DP^(k!)t5kJeXmY;4a~vG{z!wqM@Ti?ykAF} zb@oLQg4aqkh1*%tkm>sXIp_rQoRMs zs7ZNxoxg?QziDp&;2MNOwg>;WH1q56A*h}s_nu|i+c79PC3KmLq(dE|hAU0+Bdz|K zn{KCkV*?Yiga;CvE)`M+j%6N>86X+W&=!P90A3^Ys8(I}_`0lFxR|!kgm??6Mcg=J zKFWSwzEG{MvJ%+Xvc#B0-6(q+G_n*sMgJ~XdE*`;81H+bax|k6_9d7t(IN>c+?km) zMKDO78X)@t3N;o=d6F!>rw3TSlsg}dhj};8{t8s|zo$CYNO`;H8U}BVEvt1x5~*H= z;j4zuABX?m*uCJE`KuXG z!g;A6k+;^?KVaIVFNOaeC(_AOKZ84HW2VMvSrj?3l-HSw*WV94lxOlOe_Jr!A4U|R zaB=|-0aD6NnPrLlg$d)Z`=;dUJh$lCYA^Hh!zVi2%<5OZ0-J!bDa-+mFnfMhgf`O01{ac@B-%<5&74S!0 z8vQzQj)l6 zzp)kw^v!j6MY3QEG&$0~X!K=(>H-V2#PzWIG9xZ`#R~H)NTz2~g>Le=zMWx85dV_w z^dN+o%laH^KGC5cSoOVUN?4%s^2)rT=QUwc+cx~r57&aAwkCejLrs4Cu}7&@aHdQ) z74iGpd~#u&8_DU{mB$;pFHGfT)E9YvB=pGTkfTNz0Hq6TK|srzrH*q9ULg}MK$#TY zcMqrGFX26c7J|h)ZUQ{sCPrE^u1XkFEBh}rse^$pN7nW+d$F6OCdeQp5ecL)DH3^I zM6FiLfSupfa(Ti-L|Mp?tp9Ga)8^Eb8G603?7R9@!Q6SvTdc(cs()xjhq9#Vl4AYV zIZ-J=*d-~qv>Qv#s$}J_N>S+x(2$a?fTEpU&6t+A5hd_NGxP>MpaTSbdNxK$%MYb1 z1E|IhxWYIE;aZE*8b*XZSx1Dtt(7yeF7CDFm&#_M(vYaab7*p~h!izG(a89`&_$%B zdFvopEOh4}rXfRDghL%}G)60Vf++5Kbm&iava?P2f5LRhH)(kT!W^l9( zwoOnIqKalnjdFl-`F7?=4So_gHVEjatgIwH6E*}ya&WZJ9WK3yHqSY{YqR&QJ|&od zyT?g|MmBEB5@EKK2f_OA$05sPWe!zbLex%lTA5lQnFs+Z6Q?Kt(DY2J9MzCI+657; zQdnxkaN_P}0Nl0^2tF3C410}Pmeddu*6!88v~^j1E+OLjIpwiayrKAi zCqLc)g@2XI8_3B4t9&Jq_~(zcU;)=yu(jL;PvJ1TQ)k9``J~C;y|EfSXlmZEfOldU zGr+UcS}Z0wa5Z-mmnXdG3iW#)Iw>fKA4K6!8p?xuxPIeP8T1>spm!BGCM|VNB9iYC z_fvJ2G4D_V-yvHYN&ZkqY0DPEN5N71;ICH!7XeS>6(35*2oP#;d}e1{WWTe4XLoEt zyyD+LLSwYx@L$h=T8!jTzA=<*{GB~4_#AJk#S%)F13!ajQ1XZX?pA#Gjw_ky_2k0x zl&+WGXn4Yl9r48g_HXf9AkT)I@y^R*gKUN9 zAH!Jg1F_;s-M++KN!^F4cGBt=7XnM?o)X(pN8)dneePe70PA7i(p^ixXF$Z>lp{bz zro0dV>n^3HDL64D&$8qL#Ba3CS;BG7mfnUvD1??`uU;CT+_P z{$l6!%LRbdFsb!N!9X`8)JH+rhMI9w!&qz(I zgIPiV_&Wv~botNto<EhYAojS}96v%@L* z1&*_eT5M$=I(T#thI!?HR!mMzjBXy(p`>rpmEs8e6&XD`;q!MlsIWnxzUf=$sU}8S1?va>{{Q#Z_HO!po?8pe!e3jetFOjiT$o#LGf7}3e`|@ z^W}SDXPBJ&K6l8Mb@cZ6OBep%>H9$WfMWcwp@Zh)^46^d!7nE}z1xhW+)*YC*7Vv2 z=B%4gQ-+p^`(CbJV+%jUf4`o+4Ua+p{Z|9(x^Q#kPaR(c8180wVc-z%Uj~?LqfoEBc)PN7S_6OtFT~$mmg4wVr8n#1BJ7oLBx*QNGz{t zRDP&#J6|TlN(4YE1e!+!CTmP}qmB<-6u?N&VjX1EOk)Eg z9RP!B2!qM01sxJxf5=`?ph2eW?3Sx3Yjla_DLc@eV0rnq{_EB_r#lFvZT*X6j-Nro zSRLpv{47Ux2~3RIE$_1+dQSjAat0haZS}C$dZ5^(cPYwvF#w-X@N?V&N?3T&G+pB8 zQzd1lx*=tX+*E}f>sNyuht`qsUIjb1Qv6~`z!h%W_5BWn$x2rfSpMY`x!>`Nj8*Vq z-`$9QG^>?23qU`-^mJoWgXcUV;3&wh2fm=t)U2{iMOiUx82y3?fkF1`UQ-i7)W=kD zQz|J0DU9%qm@2#Vcu=41&9hhlN?zGq4!9X>^Q+lYtGA?R^0q%jYc;jtc@B6gZp<|H zfBk$v`!qH?qEulE#Z8pDa(m}b0;bR)cOO02!xx-Mp|@0!%GKRuWe31zSQEzeBFmY1;6 zShU!RB>m@RPb|CRu|hYz9!tj~$?}oBq!EVw_E%0Q!Q01Lc*Eyg?W`=gU(F5@x&wv|Ckw5F3(F21dKsV3{Q$@jrkjm&^lVrxB9jEFuPo3bQc81*rdooY`FcP`Msm2p$EVeONlf@{m zRgWY3*}^)}uvM%<;NNOn)Y^qp!&0pAV9SP~!FZN>U}TTy{)5(cpRVB9F-gfBwnI{j zt}jC9(@kFvZ1sno=)axl+lb}f_;w#@#~Act=VE^?$ix%|C^0SHB41;XYBM{jJPwZO zf^~^|T0j)z4$Fi{;JNr3@l-W`I8mOMxkFNbd51ocY)@&{wtu4svcH6(Obb}pHQzVM z)e9#ESi@@4R)p?*DHwRi7mS6%ze+6q`NV6szfUC_>HL@iGJ9{-F#TqT>CmXZS ztxf<1zWKQn7S&zM@Tj$8&L{vW;g}FIT`k|asIro0-qY6uy5@q&t%&hIHQOI}_ zJXg4Z`?b45@F=4a?P_$)!|P5mRKZa5KkA{u*v~<{1SFoDpf3?3D8`e{&?sH}C#MgF z#>V)?nK8n%u-j5F!{{ChG3fyOfz5dR_B}CMffq z*aIX+IP(V_V_R+@E{s)8Savm3iQOqukHvGKW5 zZsOjnV5nan03t0{izlg}N$k3}yuBOBoE3p3t^-*CPJCftC0f(foq|Hh48UdN;q z83l^nd(c1X7f+f>W#1Ngum6XH-H&j1yjhJDH(K(=xnqu-$r8_ND4Th?4J)A;1^Hhq z=5jfucnO5@LkmkU$-tCh_M!5_g0erX5>s!6!mYVpX=qA!HjpGwh}64AB-GwjvV#XZ>twhJ0W>@ z%Qh)l^ra?P1krZjqLB|tXoBSb1kngC_i^LXY859*rt`830I#q7VzH}?94_7kDLq8F z4Y)?E6b*nal_=i;7A_PiyPv}SnjoE*r47lu_GT1hdESZl$Z~KSTjG`bD?Mz@wkG^q zjXE;m_$gwnmTrh#TB7dpSIZNS#rq5c)&neUkt=n8c7Uhpa^(nxp9@xG1uM%rw;TD0 zEJx!t(qJxP4-QD*r_+SOR7_t%&urBz*XcOJA`R{$CLjW@ks+Un>-He=_d?l~yb8x+ z9F*cI`O7UX!}8(-t4=CKZDkJhB4{dM%ZCWL@ALfQ`uokL^&8EQC{MPV2qcY zKx8$fbra1Uvnz*_OwW&Do^&jG6HSSO6^Vmox2{<5fxJi45)Za9!(2C9XWlfc_u*hi zWm42}&;OhbT+&S)9cEM4KOWNSW`|j0)Y$6ep0bhVKA|T-XlTmVR{Y*^FdbMBJeAdW z#irGXO&KjMlxtNQUI;8lf6X#ya}6v0Zz zORblsJ8ZWL58E7XFSMw#QOT!o#|+og_mAV-jvM9ZW_`C3y8^Gdl_E5`l>N!15&c;P zoJ3ZbZ-kLfd%b-m7I3k6hDr-jM<8UxUSDrN1P_f$jZKm5gw_j%E&u=qIY~r8R5&_S zjyGv4S)TN1-AeM@wNhnAo}h%S^*8xO03*A7+{iZFhi20C z&*{gu5CvqX!kedw*ASBqDRr+vRs#zVE(rUb6p`iNB$n<#w&_&0$ch(Q#Aj{$qWFSr zQb~X!`^~tKU5@awZ07UcTTK@MzZO%e1xr4Jb@ldkZT=pH`<3bxkfr%GJ|}-`$v{I9 zS$YBKE>GuBx>bxU`ARxMiFxe=C_W%-x*R~KuzMmq;>GZ5mg`yicVaV36ES;KTCcDc zD+Lx>MG+1Qk3n0a<9n)DOGvZC#a35LH4J_G0@7UCmo*+>P3i z{cRnS)ZGEGnNC)wA0797aWD%Z10#%<$QbCuR?!Qh^8(`tc4@IDd2zTmq`G_m$CxSVcc>5gKi9LN zmNAgkz_VIr-EWNH80eurhdzrmsoyd9Eei+hngSEqyhd-31>6VaS-JCbbF;uYDz?uC zcn`sFGI##`%s$AK=jRfT)q|F1*${#km64_AWJ3qLU=mrM-DrRb$zT6FEcsS1Wdnz!8 zUmLuMd)GiuJH+-?l~?uchczfg(tvHSrK-HVs;v|(vy_pgjfk`RkFkAEV@z_vP)|xR zyI>Mo-~EFBw|8|fQAAPvR5Nq##FAld_EKv_*;8dJJxE&%QHf;F!ug8`RFZ=l3$RJ9idl&Tr5CopbKT zZ4@+nPBeFX*oHej(qG-4YsoYQ$v03Py>weQSyD3&g*+_ANA*O6eFk$p>7N;$9pzmVB!n8w9 z1tC1Of<20T!o3P}zb@g!In46~!zX30ZK3L9EvS!{mJ9jqO*V7wf9rxARmvK05zqTg zh6r2aVS9IVwr5}c#haXIGWU|`5| zb{r5HV>e69$)+fqRLyJ|p;?XA6e0LR+{qdc>t|&^DLMgMMZ4b=&WL~z+nP+bxsQCE z+f9j>Y-}R3Actx4LeGY}2v?e@_#d@}Bl&PzIQvzyoFx&M0LFAMr3o!q&C-AbWBWBp zvs*Apb*hkNjQyrfSYp9bd<=rcL9jbZ_>3WK>Ouxw#pRqg2zIUjx^Ra^l}rQL)W~ek z&ju8>>8`h|Q|;Y?)fiEuwAuWDv>vqL8_;aDhKqx7&D~j(Vb+xpaeEw0yI0<4cZQRR;uXb07lQ{`y9*J)`wAUFwOiHuOsg(a6_jgtj6v|Dfmo1 zV)V>?c4TFa(QGB+TATAcri#9%4&Oyw5zBsE*8MQKfKg6J*1ozj(fgzVu`w~8kH54} xnmD@1Xq)Jpu0%!|qAK2#+F$F&A6n&iegGvtw@E`SoZSEb002ovPDHLkV1nYWPA32W literal 0 HcmV?d00001 diff --git a/src/content/developers/docs/networking-layer/exe_cons_client_net_layer.png b/src/content/developers/docs/networking-layer/exe_cons_client_net_layer.png new file mode 100644 index 0000000000000000000000000000000000000000..0fa59d88dd1b1b7c276e8a69c772340737744220 GIT binary patch literal 7492 zcmb7}2T)T@yZ8eL_zEJgH0dZ+31A3CI*K% zfJj1bp-Tuzm)`Lo?|bje_s##_xpQaEw&&S-&Ys<~yU%Yo)<945@+FQ-AQ0%Xw$}Ye zAP@zH9C|O31t3}ZhWj88H=XwVyGDK!>(haLMxM&CeE% zf1v^bDRNyibcIYfKpKg%*8xWq;rq#3ymH98c!8Le9ouM%Op);6maUQZz6*sFFF|Nx z{P`}kZVc=ez&q92UUMvxeEObJc4O^J)B0>41R>mQ9~uKYslQvNB0U0g3l8_5q9l1# zRh)*iKwk&8&|A36>(tx?pC1jDp~g0h@b$_BPSmSxlNY;(Q|u2Us~CDtp5Go#B|L{fnwiwI|Y2mB=?{Yv=crZX5b4JbL|-{CHA{ z7Uy?`BkiL3#aGGiPMj3=Q|T?jo6k;phc6TQHL~ZEvifOALFd+y^CsDhm<9Zk4@nCJ zjZ?bW^8i~}&^tQT-_M}ggPMcpuo=zm=Vm1vhc4r+#?GP!6-hoPhDut;RpxVaS?anD zUspdnMlC78iwQWIG%Oqj5`5|_+buq8%8%o z!|cwS3N6j9#Vqj2V5eD7{l(sCF07bgJnPq|D20#vi>pbr_|e>_qs&dD0?#YI_8PsG ztWG}7Ucjg48C2wh#$H@=sufjSp~lPeGfgndcC$hrPOts#!rz^AKy?>WCyd$)+CO63 zd3|LnpL^Y;EJz@^ZJhzt7+%M9+cjBvyKE;djCO-AG0~7I4mJT)eVyl@Rm1YRKCsq- z`h<+C4Vor$KP}*qDCL%Pk#XqUc&{=ivfz?g zjqq1*Ll!-IF^XXX$)vsb+wYN*?2j+^RJ6}8zJbO(>Tj1-5?@r-lR`JylW%q znp@`*1=5PXKS}8{g*<`=xy97YBSIbEA}`Zuc@^WfjUa0VL6^CX=#%i0w*h+o424T` zC9QXuG>ixL92t+qIzzAjnS*ele^36A{cHTc=zSmUy0tFHIoflsQ3J#tycf?bLJDdM z;3k$R8azM0JxSbq+pggLK9@!ZX2%CzN~Pm~+WP*anQQvJ0bRWKap_IfTX-4-m-A4F z>f3#lK+LXa{1r~WHfD#$Yjnpx?u$<(*+I{=Y4+_`J&x`cmN1DL1{sY3mByJ-zF!iT zvz6lfgQQ-Z2A|gI?>UbKz>MY>9!$FMv$EWupRtl5Mg*Ur%C}M(34)GG$F7K~eYVbl z(WIfp<$#byr_*Mn8e$L#Pm|cN3+tdkkNGgngE`rp9dstvAl}Tq{)rQ98$%dW$>M7> zHAD@NpN*#W7I$*rI+IsXZWie5N1_S3h$}3w*h6mb7qsFz5cG-KS$ml;+FpG-q{vtv z#x>r@tHJ*WU9oi3cAagxMfy;CSm{Jtv23xkufB)AEovGzKT?RopoiJHxGa~mg34c=&43KiZm@@Fy8-KpFLJ6Hr5^Lh(v@Eemc$a}lt!u~aztJA^N6_G&S%;zae*FCj zC6~)CgJDCm`+Pj^t+@#Yz!p+8s94f zfkqJK91l|UK#9FIkCKt>pA$?^p#+f4lP7=LIJg!qXr)IP>QVLW9LEQ!e2wm%vwM|U z8Gvb(HVj$~;LbV<(5`9}KLvj~Upz56J$)DLxMyn2bzlNJ^~nDAiLhZO%JV{Oc_&(8 zE;s6Zxv8n(L`fZdJ75|mO|%RU{mPMVN(r*!HZ1@6$m75S#}PMqzZaiJ4H_0Y@$qMw z6jH~zc?sqe(0Gh&1N#bVaVz$%PQ$#)O*F;H(PP_LEV6+~Soa%az@+WOF{$$VLY}L} zwkw)Gp2ZPmFKTdAQ)~>#SFvzzTv9t8#dVF~t#%UEKlX~uGTP{?*Co?iB&*P_)>+Hi zcTUqTON+YAHtmJ|ir7_}sr|jt2+gB=ue;E>wjRB&sDyD+zj8#^qF2N1qn08mHV_#? z0ZO0XOXBM|$TL0J|=2ewy;vCjfj%_dB%dx?4M^ z90#X)s0yZvLq+IB`#-i;BUCYauIw65*66G6H_xvzt)bXz7l+VvV`bBhZ07wMRfJ(( z26A_5@Bij{GaW(IqvdN_Nsm$&+Rf69?*9A$i_b8q!i5new0TTcqO@wh(v#X_YVLb* zArr2Sly|y)Y}RU8D>+6in}JjzLeiwV{5lY8JeIPS8ZW*}vqSG0PuX(Eg_GKgv5GLC ztn*X4Z#yLnDryBim8~vhRPsiw3vhiSu&=91P=2eUcE^^=fS&p8q|kv*0)K`x zW_@Mupu3rhA4e%;w4OY(R3+&DE?DgwSkjgUKgHssb`olT#{a#x_LpW0m(DIl&c?tX zJ`NsFnpnI2y;=LYpfa4!R~^-8;GtMH6Np^C9unts9rG>XE6$gMLytaGj%;p_l5)~~ z?HD@?KRBI#Mk85yJteC|D$lIfD@Y-IDbMsnf=g%4>* z9C79WcG}!=OY_fX=z3t-y<`@^?m0WoqWz?D2Dd%uvmcVWJFw{FY(^Yam%b9ettLj_ zaj@s8vpo&;;YExKEwD$PWh-*(nm;+ODRPd4@PbIW-;O$eMSR92*T)gb6)uy$xkOQl zDEySxL{axhVG%z`7eFG_@>-@}W)WP&19I@^B@aIh_{||V(`nz(s>DNW1+Ge^Xk(JX z&cv<1)EsW{E~SjZ3oh&}CogTACoFOac)(7PO`+Z(bra__B>Pu1XSuc>hzn%~K!z9< zDpd+f!EP=czf)`BlvuDP;Mi3`JQd*nP)0lcutVoJVErjh09MA3czIdy20SCaaqTno zmdP)Sw3rm62W!EaBUg|&eUZg1E$~Syk~D>O#%X8XXn2>uJh|3c)c|e6!87*mSk&AG zjshS<<*46f80C25nRKTcHvm{ZHiQ-Hzi3=WC`8%?GDytL`2DUau2;f>d!T;qF2<*; zM{7Kgp?pG5kzGFU0)+*~LmDm&DQg*Y@dE*pUbbpwZtt8Ee4y+menT>OKRBa<&i1NN@U~o6{)|fcgr|U4V_3_>hrH$aI1&xKIBi7# zMj$iv6S~!S(sdMGTyj8P|3C$rgIeoLa2&k_Xh5Au(qm#!l_u7Y_eFr?Cqbed9XJQM zn5gI95&|%!$UNDMX+xW*n$=DHc=2PmFqBUO?^&TR=J=RC3*S`Jj5!2Iw<$4-v<&-F4QTToY_DHUlu_?=_)MN@ykCVB`m-SH)l^22X>q2dhKi7bAt; zS(WTEv~Zk&V<-Dko(LDF2_yUJwXpFey!$=$>}`;`ee(8uX7HGX5Uox3VXG8c820zok+kKMqCRgyD@5} ziLMg#m`&!*f+RfGo)9wygr@5q-VZ&G&ZXv)`E|B1yPK2URB%~or_7&Knxj8dA2t^ zmC(bAO%FH2kofe!p`Po61{cD9l3TbVw?cpY)@*0t#@F=X-mXo1hSi9aa6}of+iGA= zsn(f(a!}N8w!NEOQg~Ah5J+yBXxYCTcq?UiS_Fa!Px|aRLZ-qn}Ejc9^xX|vb&(a*n1>t7HzzP zc-est#W`h>e<$FGU`F<*X(T7%{gdjN7!;Krgfj?84Zqf><9Wu_r2&EFz?kH*xMzSk zAwN+W+Rcg8!Cmd>>lXuPpw1DRIE{SN0$(RI&BD41XuYB`z7vZikwL~UI>`3|Z-j@J z`9k=SY;fvSF{nK!2%cdNRfr04`)hW!<>t!Qb&74__Jl58qtNGeA;q#7X#v7-0pM~q zwWv13r=o)JDhhM$ zQ{U&Uo5=2UgLswZFVp3l*RbF!;BpZ^o^^9|ZOz-rMv(Aw@(QowxLf%A#+SNax#H1s z*zNSs@2{8>BIVn-9BZAvM?hS!9g2HOS{35GG8DNAC@?V-0f* zU*Ie3*YOM@%Pv4n$W^0?{-dVys3opLhy3URRuE_^Dq29v@4hD^5jg@rh_KRMFLQrw zF?$ivMKo_RxyA$8~jm7s~5TkC-HBBW>* z-vM6Y#y^1cM8h^0vn!FlG6^jI9lWjI?6?uwI^WCbR6_CCg#8t4eTR)Ljuh#CbXIQZw-CzNydQ&77g`*?mu7m3#K zms#veVUvtkMUzx5lbg=$njvnr@CWgLSQ1objT!BEdsWzU0^qEUiDX>2gX;bKnBT}D z@mGpvs&D12%)V2|U8F~ss=ifxs|*x}#sN6KCd6e1c#2YA5^=Wq0!2;)9;stlbUDmhP0# z&C7v>bRW>gCh*#z^zb{!kV%5Q16LTPgY&LG*5%kh zFk)Wzabm&QRAdDn2OAXtIwglvA#tcmTy0t`$_-cS(7Izx<~XSw7!Bgf!ZN0+@hESR z3Z5~&m!I00?UpfRps@1=1IqcmsiM0QTsjwd0bcBp=p;Ek|7r)7jl&|Fj(Y?KuVf-g zLkR-@^H+9ko_HFFq8=Z^&hc8l7N(E3%~aK}SpwZ1XrVyY5bw!lOtL`bqW1ol3_Jrr zdZ4Ggl$<`>=E`Dx9c(* z(mN)Z28o09;tu(I(*(Ftd`y@eB)1Y#FLi-A^SJRQwHDj#_NC%+(n>eKEIm=G&J~~y!vGV zD&Q^8tDuBH^?iF9$O*f$H;qJii}y%&taY`6WtAw@T4GsxOkIh(<~Qn~R(GYM=5WWg zK9CScYyI%}^aq_^$@P_$5#!i>#|mVNl_r4q%bfZCGqH_Zv`%-z9O5j}2lP>boYI0~ zNaf=)H{rh7qCYN3$CPK#VrFeky;W8x2^Y~LcU=3b6_XSH9oG_G{THo0{~u_LZ}+97Tbd`Is9uqq&$V(CXy! z%M1FwZGoocZWa5UW+Ro4+KNNt{z8Bil=U<+M0NU=`Db8%ivAx^+kP*DaT%pNMFou< zLJ0bU2Ow6Ox8J4kKU-`M`fH<%^tQT?HhnDx(kg&uLxzCsIF_|`z*)v8EgZmBxTV$! zkL~;?lAS3`=?+@{ElKxUvkv8hu})P)zqhVtfTmONf4_?Lu#tT5vKiVuy>Vl?CVwTl z2tfhDB8SsUf=4OMz^rurtWwSW4+HdN;)i##?2o>+!?DvZWwktQzkwg|xItHeW~~4` z$!+@=cl(su*Pg3gnhjhchRwbAb%m?eJUTq>_c?7oPc?e6jrv@`gU^vbN`Mo~1oOux zAIh-^+&z+^D=>{t{EQ7^GN?}$8Di8M2QgEr_t$qTF%e@(y)MmJ+#%Z=?WOn|dpBh8 zez8y8Nm`iqGG6e-%J-ZTw2G^|hQ&pZD)V+eHekwUQJN2BMdQRW6fj>!Hif2NAI6A{ zv&@1YNx*kxZYeG#Lk7WRcy#tiKzGSAw#@lV;s1uo82&#doAA*xBR!MvEc6|YjJI0%g50g=#}a4WBL z*aw}*icwa2pwO%3;ogF$N}YEtbNGFqHw{yjh9Q)7_wGSHEL{wwQhV)l-r<9>8-;wB zB|S7_RXHar4nCnzFHk<)aiuvFD`sNRWcRyR53bGCVMuKN2kTg>%7@-4uX8j)QZG`` zi59$oTVUMKLUI((p2AUyzq0LTp-|g;dy=m71kTqYMD;OjYCPt*pdXVcIj{i_{Payxt4Zt6AvSKXI{m93`MN8uEzcCg#yDNEy)i3ia9N)yk#20JkboO?i z92!hyO%0`zcVxg4p(k%lObsq}$8fgI_x_ZOhm8`Sb$>yUR_ zb60gv`0jF(Pu99|(%iETy`fP{HDn%4B($oRB%k=tJ9XQWtrbOm9AQm#@83H1=5%o z<+Jzd?Av!rIkP|uQFTra?sw>zmRH>*!(C8CE6Zi_0Vdb|uL@5!J`uL>^>OxWh}^Cz zG_(8(umyc=$I1VC%Ya{5g_3>x@08F$?nxhq48A~}-nIQfRa=yjp|?&nVCYccnEff@ z&vHiU9r&af&GtvCmv@&<6Mpdr@|p4arQ#VyV^YL+)Mn zanTTMW$3uZl_pK(b`Vd$u&~*8YBmPsB;NQVl;Lc0atX9W29@~H`nW8`|HY*^0h!|5*J;;N z|J<8XXO)cKiN9rdd`dsDiSV}N%b}Sx7?Mh}22Sp|{zcFJcw;tme!pkPJuj)49+jfF z?X)vNyB-xM99(_0J}jGeJ*0$(^zSzW|5^IiD};aY|6c8X)BhjL$U&Pu8zVaV6HyWS e{n3QqR4sGPH!R)_qW@fvYOCwrue@jT^8W$a=g>(2 literal 0 HcmV?d00001 diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md new file mode 100644 index 00000000000..72f32dcc20e --- /dev/null +++ b/src/content/developers/docs/networking-layer/index.md @@ -0,0 +1,152 @@ +--- +title: Networking layer +description: An introduction to Ethereum's networking layer. +lang: en +sidebar: true +sidebarDepth: 2 +--- + +Ethereum's networking layer is the stack of protocols that allows nodes to find each other and exchange information. After the merge there will be two pieces of client software (execution clients and consensus clients) each with their own separate networking stack. As well as communicating with other nodes on the Ethereum network, the execution and consensus clients also have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication to take place. + +## The Execution Layer {execution-layer} + +The execution layer's networking protocols can be divided into two stacks: the first is the discovery stack which is built on top of UDP and allows a new node to find peers to connect to. The second is the [DevP2P](https://github.com/ethereum/devp2p) stack that sits on top of TCP and allows nodes to exchange information. These layers act in parallel, with the discovery layer feeding new network participants into the network, and the DevP2P layer enabling their interactions. DevP2P is itself a whole stack of protocols that are implemented by Ethereum to establish and maintain the peer-to-peer network. + +### Discovery {discovery} + +Discovery is the process of finding other nodes in network. This is bootstrapped using a small set of bootnodes that are [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) into the client. These bootnodes exist to introduce a new node to a set of peers - this is their sole purpose, they do not participate in normal client tasks like syncing the chain, and they are only used the very first time a client is spun up. + +The protocol used for the node-bootnode interactions is a modified form of [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) which uses a distributed hash table to share lists of nodes. Each node has a version of this table containing information required to connect to its closest peers. This "closeness" is not geographical - distance is defined by the similarity of the node's ID. Each node's table is regularly refreshed as a security feature. In the [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) discovery protocol nodes are also able to send "ads" that display the subprotocols that client supports, allowing peers to negotiate about the protocols they can both use to communicate over. + +Discovery starts wih a game of PING-PONG. A successful PING-PONG "bonds" the new node to a boot node. The initial message that alerts a boot node to the existence of a new node entering the network is a `PING`. This `PING` includes hashed information about the new node, the boot node and an expiry time-stamp. The boot node receives the PING and returns a `PONG` containing the `PING` hash. If the `PING` and `PONG` hashes match then the connection between the new node and boot node is verified and they are said to have "bonded". + +Once bonded, the new node can send a `FIND-NEIGHBOURS` request to the boot node. The data returned by the boot node includes a list of peers that the new node can connect to. If the nodes are not bonded, the `FIND-NEIGHBOURS` request will fail, so the new node will not be able to enter the network. + +Once the new node receives a list of neighbours from the boot node, it begins a PING-PONG exchange with each of them. Successful PING-PONGs bond the new node with its neighbours, enabling message exchange. + +``` +start client --> connect to boot node --> bond to boot node --> find neighbours --> bond to neighbours +``` + +#### ENR: Ethereum Node Records + +The [Ethereum Node Record (ENR)](/developers/docs/networking-layer/network addresses/) is an object that contains three basic elements: a signature (hash of record contents made according to some agreed identity scheme), a sequence number that tracks changes to the record, and an arbitrary list of key:value pairs. This is a future-proof format that allows easier exchange of identifying information between new peers and is the preferred [network address](/developers/docs/networking-layer/network-addresses) format for Ethereum nodes. + +#### Why is discovery built on UDP? {why-udp} + +UDP does not support any error checking, resending of failed packets, or dynamically opening and closing connections - instead it just fires a continuous stream of information at a target, regardless of whether it is successfully received. This minimal functionality also translates into minimal overhead, making this kind of connection very fast. For discovery, where a node simply wants to make its presence known in order to then establish a formal connection with a peer, UDP is sufficient. However, for the rest of the networking stack, UDP is not fit for purpose. The informational exchange between nodes is quite complex and therefore needs a more fully featured protocol that can support resending, error checking etc. The additional overhead associated with TCP is worth the additional functionality. Therefore, the majority of the P2P stack operates over TCP. + +## DevP2P {devp2p} + +After new nodes enter the network, their interactions are governed by protocols in the DevP2P stack. These all sit on top of TCP and include the RLPx transport protocol, wire protocol and several sub-protocols. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) is the protocol governing initiating, authenticating and maintaining sessions between nodes. RLPx encodes messages using RLP (Recursive Length Prefix) which is a very space-efficient method of encoding data into a minimal structure for sending between nodes. + +A RLPx session between two nodes begins with an initial cryptographic handshake. This involves the node sending an auth message which is then verified by the peer. On successful verification, the peer generates an auth-acknowledgement message to return to the initiator node. This is a key-exchange process that enables the nodes to communicate privately and securely. A successful cryptographic handshake then triggers both nodes to to send a "hello" message to one another "on the wire". The wire protocol is initiated by a successful exchange of hello messages. + +The hello messages contain: + +- protocol version +- client ID +- port +- node ID +- list of supported sub-protocols + +This is the information required for a successful interaction because it defines what capabilities are shared between both nodes and configures the communication. There is a process of sub-protocol negotiation where the lists of sub-protocols supported by each node are compared and those that are common to both nodes can be used in the session. + +Along with the hello messages, the wire protocol can also send a "disconnect" message that gives warning to a peer that the connection will be closed. The wire protocol also includes PING and PONG messages that are sent periodically to keep a session open. The RLPx and wire protocol exchanges therefore establish the foundations of communication between the nodes, providing the scaffolding for useful information to be exchanged according to a specific sub-protocol. + +### Sub-protocols {sub-protocols} + +#### Eth (wire protocol) {wire-protocol} + +Once peers are connected and an RLPx session has been started, the wire protocol defines how peers communicate. There are three main tasks defined by the wire protocol: chain synchronization, block propagation and transaction exchange. Chain synchronization is the process of validating blocks near head of the chain, checking their proof-of-work data and re-executing their transactions to ensure their root hashes are correct, then cascading back in history via those blocks' parents, grandparents etc until the whole chain has been downloaed and validated. State sync is a faster alternative that only validates block headers. Block propagation is the process of sending and receiving newly mined blocks. Transaction exchnage refers to exchangign pending transactions between nodes so that miners can select some of them for inclusion in the next block. Detailed information about these tasks are available [here](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Clients that support these sub-protocols exose them via the [json-rpc](/developers/docs/apis/json-rpc). + +#### les (light ethereum subprotocol) {les} + +This is a minimal protocol for syncing light clients. Traditionaly this protocol has rarely been used because full nodes are required to serve data to light clients without being incentivized. The default behaviour of execution clients is not to serve light client data over les. More information is available in the les [spec](https://github.com/ethereum/devp2p/blob/master/caps/les.md). + +#### Snap {snap} + +The [snap protocol](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) is an optional extension that allows peers to exchange snapshots of recent states, allowing peers to verify account and storage data without having to download intermediate Merkle trie nodes. + +#### Wit (witness protocol) {wit} + +The [witness protocol](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) is an optional extension that enables exchange of state witnesses between peers, helping to sync clients to the tip of the chain. + +#### Whisper {whisper} + +This was a protocol that aimed to deliver secure messaging between peers without writing any information to the blockchain. It was part of the DevP2p wire protocol but is now deprecated. Other [related projects](https://wakunetwork.com/) exist with similar aims. + +## Execution layer networking after the merge {execution-after-merge} + +After the merge, an Ethereum node will run an execution client and a consensus client. The execution clients will operate similary to today, but with the proof-of-work consensus and block gossip functionality removed. The EVM, validator deposit contract and selecting/executing transactions from the mempool will still be the domain of the execution client. This means execution clients still need to participate in transaction gossip so that they can manage the transaction mempool. This requires encrypted communication between authenticated peers meaning the networking layer for consensus clients will still be a critical component, includng both the discovery protocol and DevP2P layer. Encoding will continue to be predominantly RLP on the execution layer. + +## The consensus layer {consensus-layer} + +The consensus clients participate in a separate peer-to-peer network with a different specification. Consensus clients need to participate in block gossip so that they can receive new blocks from peers and broadcast them when it is their turn to be block proposer. Similarly to the execution layer, this first requires a discovery protocol so that a node can find peers and establish secure sessions for exchanging blocks, attestations etc. + +### Discovery {consensus-discovery} + +Similarly to the execution clients, consensus clients use [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) over UDP for finding peers. The consensus layer implementation of discv5 differs from that of the execution clients only in that it includes an adaptor connecting discv5 into a [libP2P](https://libp2p.io/) stack, deprecating devP2P. The execution layer's RLPx sessions are deprecated in favour of libP2P's noise secure channel handshake. + +### ENRs {consensus-enr} + +The ENR for consensus nodes includes the node's public key, IP address, UDP and TCP ports and two consensus-specific fields: the attestation subnet bitfield and eth2 key. The former makes it easier for nodes to find peers participating in specific attestation gossip sub-networks. The eth2 key contans information about which Ethereum fork version the node is using, ensuring peers are connecting to the right Ethereum. + +### libP2P {libp2p} + +The libP2P stack supports all communications after discovery. Clients can dial and listen on IPv4 and/or IPv6 as defined in their ENR. The protocols on the libP2P layer can be subdivided into the gossip and req/resp domains. + +### Gossip {gossip} + +The gossip domain includes all information that has to spread rapidly throughout the network. This includes beacon blocks, proofs, attestations, exits and slashings. This is transmitted using libP2P gossipsub v1 and relies on various metadata being stored locally at each node, including maximum size of gossip payloads to receive and transmit. Detailed information about the gossip domain is available [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). + +### Req/Resp {req-resp} + +The request/response domain contains protocols for clients requesting specific information from their peers. Examples include requesting specific Beacon blocks matching certain root hashes or within a range of slots. The responses are always returned as snappy-compressed SSZ encoded bytes. + +## Why does the consensus client prefer SSZ to RLP? {ssz-vs-rlp} + +SSZ stands for simple serialization. It uses fixed offsets that make it easy to decode individual parts of an encoded message without having to decode the entire structure, which is very useful for the consensus client as it can efficiently grab specific pieces of information from encoded messages. It is also designed specifically to integrate with Merkle protocols, with related efficiency gains for Merkleization. Since all hashes in the consensus layer are Merkle roots, this adds up to a significant improvement. SSZ also guarantees unique representations of values. + +## Connecting the execution and consensus clients + +After the merge, both consensus and execution clients will run in parallel. They need to be connected together so that the consensus client can provide instructions to the execution client and the execution client can pass bundles of transactions to the consensus client to include in Beacon Blocks. This communication between the two clients can be achieved using a local RPC connection. Since both clients sit behind a single network identity, they share a ENR (Ethereum node record) which contains a separate key for each client (eth1 key and eth2 key). + +A summary of the control flow is shown beloiw, with the relevant networking stack in brackets. + +##### When consensus client is not block producer: + +- consensus client receives a block via the block gossip protocol (consensus p2p) +- consensus client prevalidates the block, i.e. ensures it arrived from a valid sender with correct metadata +- The transactions in the block are sent to the execution layer as an execution payload (local RPC connection) +- The execution layer executes the transactions and validates the state in the block header (i.e. checks hashes match) +- execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) +- consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) + +##### When consensus client is block producer + +- consensus client receives notice that it is the next block producer (consensus p2p) +- consensus layer calls `create block` method in execution client (local RPC) +- execution layer accesses the transaction mempool which has been populated by the transaction gossip protocol (execution p2p) +- execution client bundles transactions into a block, executes the transactions and generates a block hash +- consensus client grabs the transactions and block hash from the consensus client and adds them to the beacon block (local RPC) +- consensus client broadcasts the block over the block gossip protocol (consensus p2p) +- other clients receive the proposed block via the block gossip protocol and validate as described above (consensus p2p) + +Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalised. + +

+ +

+ + +Network layer schematic for post-merge consensus and execution clients, from [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) +

+ +## Further Reading: + +[kademlia to discv5](https://vac.dev/kademlia-to-discv5) +[kademlia paper](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) +[intro to Ethereum p2p](https://p2p.paris/en/talks/intro-ethereum-networking/) +[eth1/eth2 relationship](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) +[merge and eth2 client details video](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md b/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md new file mode 100644 index 00000000000..cf2af6cded4 --- /dev/null +++ b/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md @@ -0,0 +1,11 @@ +--- +title: Network addresses +description: An introduction to network addresses. +lang: en +sidebar: true +sidebarDepth: 2 +--- + +Ethereum nodes have to identify themselves with some basic information so that they can connect to peers. To ensure this information can be interpreted by any potential peer it is relayed in one of three standardized formats that any Ethereum node can understand. + +Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddresses and enodes. From 4ed547b006d347a61ee5876adad0c95c15c7c09b Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 29 Mar 2022 14:12:25 +0100 Subject: [PATCH 02/31] finish draft network-addr page --- .../network-addresses/network-addresses.md | 24 +++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md b/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md index cf2af6cded4..653d517d83e 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md +++ b/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md @@ -6,6 +6,26 @@ sidebar: true sidebarDepth: 2 --- -Ethereum nodes have to identify themselves with some basic information so that they can connect to peers. To ensure this information can be interpreted by any potential peer it is relayed in one of three standardized formats that any Ethereum node can understand. +Ethereum nodes have to identify themselves with some basic information so that they can connect to peers. To ensure this information can be interpreted by any potential peer it is relayed in one of three standardized formats that any Ethereum node can understand: multiaddr, enode and Ethereum Node Records. -Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddresses and enodes. +## Multiaddr {multiaddr} + +The original network address format was the "multiaddr". This is a universal format not only designed for Ethereum nodes but other peer-to-peer networks too. Addresses are represented as key-value pairs with keys and values separated with a forward slash, e.g. the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: + +`/ip6/192.168.22.27/tcp/33000` + +For an Ethereum node, the multiaddr has the node-ID (hash of their public key), for example: + +`/ip6/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` + +## Enode {enode} + +An ethereum node can also be described using the enode URL scheme. The hexadecimal node-ID is encoded in the username portion of the URLseparated from the host using an @ sign. The hostname can only be given as an IP address, DNS nammes are not allowed. The port in the host name section is the TCP listening port. If the TCP and UDP (discovery) ports differ the UDP port is specified as a query parameter "discport". + +In the following example, the node URL describes a node with IP address `10.3.58`, TCP port `30303` and UDP discovery port `30301`. + +`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` + +## Ethereum Node Records (ENRs) {enr} + +Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddresses and enodes. These are especially useful because they allow greater informational exchange between nodes. The ENR contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures. The rest of the record can be populated with arbitrary data organised as key-value pairs. These key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use. Consensus clients use a [specific ENR structure](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) to identify boot nodes and also include an `eth2` field containing information about the current Ethereum fork and the attestation gossip subnet (this connects the node to a particular set of peers whose attestations are aggregated together). From 7544e75202f52947b9a0b7a3a349d3ba05ad1fc8 Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 29 Mar 2022 14:31:25 +0100 Subject: [PATCH 03/31] add formatting for eth.org --- .../developers/docs/networking-layer/index.md | 13 ++++++++++--- .../network-addresses/network-addresses.md | 10 ++++++++++ 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 72f32dcc20e..0399da524af 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -8,6 +8,10 @@ sidebarDepth: 2 Ethereum's networking layer is the stack of protocols that allows nodes to find each other and exchange information. After the merge there will be two pieces of client software (execution clients and consensus clients) each with their own separate networking stack. As well as communicating with other nodes on the Ethereum network, the execution and consensus clients also have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication to take place. +## Prerequisites {prerequisites} + +Some knowledge of Ethereum [nodes and clients](/src/content/developers/docs/nodes-and-clients/) will be helpful for understanding this page. + ## The Execution Layer {execution-layer} The execution layer's networking protocols can be divided into two stacks: the first is the discovery stack which is built on top of UDP and allows a new node to find peers to connect to. The second is the [DevP2P](https://github.com/ethereum/devp2p) stack that sits on top of TCP and allows nodes to exchange information. These layers act in parallel, with the discovery layer feeding new network participants into the network, and the DevP2P layer enabling their interactions. DevP2P is itself a whole stack of protocols that are implemented by Ethereum to establish and maintain the peer-to-peer network. @@ -136,15 +140,18 @@ A summary of the control flow is shown beloiw, with the relevant networking stac Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalised.

- +

- + Network layer schematic for post-merge consensus and execution clients, from [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)

-## Further Reading: +## Further Reading +[DevP2p](https://github.com/ethereum/devp2p) +[LibP2p](https://github.com/libp2p/specs) +[Consensus layer network specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia to discv5](https://vac.dev/kademlia-to-discv5) [kademlia paper](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [intro to Ethereum p2p](https://p2p.paris/en/talks/intro-ethereum-networking/) diff --git a/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md b/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md index 653d517d83e..3df7d844828 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md +++ b/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md @@ -8,6 +8,10 @@ sidebarDepth: 2 Ethereum nodes have to identify themselves with some basic information so that they can connect to peers. To ensure this information can be interpreted by any potential peer it is relayed in one of three standardized formats that any Ethereum node can understand: multiaddr, enode and Ethereum Node Records. +## Prerequisites {#prerequisites} + +Some understanding of Ethereum's [networking layer](/src/content/developers/docs/networking-layer/) will be helpful to understand this page. + ## Multiaddr {multiaddr} The original network address format was the "multiaddr". This is a universal format not only designed for Ethereum nodes but other peer-to-peer networks too. Addresses are represented as key-value pairs with keys and values separated with a forward slash, e.g. the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: @@ -29,3 +33,9 @@ In the following example, the node URL describes a node with IP address `10.3.58 ## Ethereum Node Records (ENRs) {enr} Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddresses and enodes. These are especially useful because they allow greater informational exchange between nodes. The ENR contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures. The rest of the record can be populated with arbitrary data organised as key-value pairs. These key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use. Consensus clients use a [specific ENR structure](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) to identify boot nodes and also include an `eth2` field containing information about the current Ethereum fork and the attestation gossip subnet (this connects the node to a particular set of peers whose attestations are aggregated together). + +## Further Reading + +[ENR EIP](https://eips.ethereum.org/EIPS/eip-778) +[Network addresses in Ethereum](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) +[LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) From 55f4ae84cf64d54b69c63050d07f135eea028abb Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 29 Mar 2022 14:45:29 +0100 Subject: [PATCH 04/31] rename file to index.md --- .../network-addresses/{network-addresses.md => index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/content/developers/docs/networking-layer/network-addresses/{network-addresses.md => index.md} (100%) diff --git a/src/content/developers/docs/networking-layer/network-addresses/network-addresses.md b/src/content/developers/docs/networking-layer/network-addresses/index.md similarity index 100% rename from src/content/developers/docs/networking-layer/network-addresses/network-addresses.md rename to src/content/developers/docs/networking-layer/network-addresses/index.md From f7fceeeb00fd99adf3eb0546fdc50b4c2fa28c21 Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 30 Mar 2022 11:52:19 +0100 Subject: [PATCH 05/31] update menus --- src/data/developer-docs-links.yaml | 6 ++++++ src/intl/en/page-developers-docs.json | 3 +++ src/intl/en/page-developers-index.json | 5 ++++- src/pages/developers/index.js | 7 +++++++ 4 files changed, 20 insertions(+), 1 deletion(-) diff --git a/src/data/developer-docs-links.yaml b/src/data/developer-docs-links.yaml index 1ba59bac1de..a9949ec2684 100644 --- a/src/data/developer-docs-links.yaml +++ b/src/data/developer-docs-links.yaml @@ -178,3 +178,9 @@ to: /developers/docs/scaling/plasma/ - id: docs-nav-scaling-validium to: /developers/docs/scaling/validium/ + - id: docs-nav-networking-layer + to: /developers/docs/networking-layer/ + description: docs-nav-networking-layer-description + items: + - id: docs-nav-networking-layer-network-addresses + to: /developers/docs/networking-layer/network-addresses/ diff --git a/src/intl/en/page-developers-docs.json b/src/intl/en/page-developers-docs.json index ea46a01a1e0..ce51571b92d 100644 --- a/src/intl/en/page-developers-docs.json +++ b/src/intl/en/page-developers-docs.json @@ -93,6 +93,9 @@ "docs-nav-transactions-description": "Transfers and other actions that cause Ethereum's state to change", "docs-nav-web2-vs-web3": "Web2 vs Web3", "docs-nav-web2-vs-web3-description": "The fundamental differences that blockchain-based applications provide", + "docs-nav-networking-layer": "Networking layer", + "docs-nav-networking-layer-description": "Explanation of Ethereum's networking layer", + "docs-nav-networking-layer-network-addresses": "Network addresses", "page-calltocontribute-desc-1": "If you're an expert on the topic and want to contribute, edit this page and sprinkle it with your wisdom.", "page-calltocontribute-desc-2": "You'll be credited and you'll be helping the Ethereum community!", "page-calltocontribute-desc-3": "Use this flexible", diff --git a/src/intl/en/page-developers-index.json b/src/intl/en/page-developers-index.json index 3cbda339ac8..f58687a2cda 100644 --- a/src/intl/en/page-developers-index.json +++ b/src/intl/en/page-developers-index.json @@ -84,5 +84,8 @@ "page-developers-transactions-desc": "The way Ethereum state changes", "page-developers-transactions-link": "Transactions", "page-developers-web3-desc": "How the web3 world of development is different", - "page-developers-web3-link": "Web2 vs Web3" + "page-developers-web3-link": "Web2 vs Web3", + "page-developers-networking-layer": "Networking Layer", + "page-developers-data-structures-link": "Networking Layer", + "page-developers-data-structures-desc": "Introduction to the Ethereum networking layer" } diff --git a/src/pages/developers/index.js b/src/pages/developers/index.js index d1a20b9bc4d..32913d48299 100644 --- a/src/pages/developers/index.js +++ b/src/pages/developers/index.js @@ -514,6 +514,13 @@ const DevelopersPage = ({ data }) => {

+ + + + +

+ +

From 53ed215dd9065c81d8923d37c57ea6ea704fc204 Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 30 Mar 2022 12:03:07 +0100 Subject: [PATCH 06/31] fix page links and page-dev-index links --- .../developers/docs/networking-layer/index.md | 44 +++++++++---------- src/intl/en/page-developers-index.json | 4 +- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 0399da524af..16323368fc8 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -8,15 +8,15 @@ sidebarDepth: 2 Ethereum's networking layer is the stack of protocols that allows nodes to find each other and exchange information. After the merge there will be two pieces of client software (execution clients and consensus clients) each with their own separate networking stack. As well as communicating with other nodes on the Ethereum network, the execution and consensus clients also have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication to take place. -## Prerequisites {prerequisites} +## Prerequisites {#prerequisites} Some knowledge of Ethereum [nodes and clients](/src/content/developers/docs/nodes-and-clients/) will be helpful for understanding this page. -## The Execution Layer {execution-layer} +## The Execution Layer {#execution-layer} The execution layer's networking protocols can be divided into two stacks: the first is the discovery stack which is built on top of UDP and allows a new node to find peers to connect to. The second is the [DevP2P](https://github.com/ethereum/devp2p) stack that sits on top of TCP and allows nodes to exchange information. These layers act in parallel, with the discovery layer feeding new network participants into the network, and the DevP2P layer enabling their interactions. DevP2P is itself a whole stack of protocols that are implemented by Ethereum to establish and maintain the peer-to-peer network. -### Discovery {discovery} +### Discovery {#discovery} Discovery is the process of finding other nodes in network. This is bootstrapped using a small set of bootnodes that are [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) into the client. These bootnodes exist to introduce a new node to a set of peers - this is their sole purpose, they do not participate in normal client tasks like syncing the chain, and they are only used the very first time a client is spun up. @@ -32,15 +32,15 @@ Once the new node receives a list of neighbours from the boot node, it begins a start client --> connect to boot node --> bond to boot node --> find neighbours --> bond to neighbours ``` -#### ENR: Ethereum Node Records +#### ENR: Ethereum Node Records {#enr} The [Ethereum Node Record (ENR)](/developers/docs/networking-layer/network addresses/) is an object that contains three basic elements: a signature (hash of record contents made according to some agreed identity scheme), a sequence number that tracks changes to the record, and an arbitrary list of key:value pairs. This is a future-proof format that allows easier exchange of identifying information between new peers and is the preferred [network address](/developers/docs/networking-layer/network-addresses) format for Ethereum nodes. -#### Why is discovery built on UDP? {why-udp} +#### Why is discovery built on UDP? {#why-udp} UDP does not support any error checking, resending of failed packets, or dynamically opening and closing connections - instead it just fires a continuous stream of information at a target, regardless of whether it is successfully received. This minimal functionality also translates into minimal overhead, making this kind of connection very fast. For discovery, where a node simply wants to make its presence known in order to then establish a formal connection with a peer, UDP is sufficient. However, for the rest of the networking stack, UDP is not fit for purpose. The informational exchange between nodes is quite complex and therefore needs a more fully featured protocol that can support resending, error checking etc. The additional overhead associated with TCP is worth the additional functionality. Therefore, the majority of the P2P stack operates over TCP. -## DevP2P {devp2p} +## DevP2P {#devp2p} After new nodes enter the network, their interactions are governed by protocols in the DevP2P stack. These all sit on top of TCP and include the RLPx transport protocol, wire protocol and several sub-protocols. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) is the protocol governing initiating, authenticating and maintaining sessions between nodes. RLPx encodes messages using RLP (Recursive Length Prefix) which is a very space-efficient method of encoding data into a minimal structure for sending between nodes. @@ -58,61 +58,61 @@ This is the information required for a successful interaction because it defines Along with the hello messages, the wire protocol can also send a "disconnect" message that gives warning to a peer that the connection will be closed. The wire protocol also includes PING and PONG messages that are sent periodically to keep a session open. The RLPx and wire protocol exchanges therefore establish the foundations of communication between the nodes, providing the scaffolding for useful information to be exchanged according to a specific sub-protocol. -### Sub-protocols {sub-protocols} +### Sub-protocols {#sub-protocols} -#### Eth (wire protocol) {wire-protocol} +#### Eth (wire protocol) {#wire-protocol} Once peers are connected and an RLPx session has been started, the wire protocol defines how peers communicate. There are three main tasks defined by the wire protocol: chain synchronization, block propagation and transaction exchange. Chain synchronization is the process of validating blocks near head of the chain, checking their proof-of-work data and re-executing their transactions to ensure their root hashes are correct, then cascading back in history via those blocks' parents, grandparents etc until the whole chain has been downloaed and validated. State sync is a faster alternative that only validates block headers. Block propagation is the process of sending and receiving newly mined blocks. Transaction exchnage refers to exchangign pending transactions between nodes so that miners can select some of them for inclusion in the next block. Detailed information about these tasks are available [here](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Clients that support these sub-protocols exose them via the [json-rpc](/developers/docs/apis/json-rpc). -#### les (light ethereum subprotocol) {les} +#### les (light ethereum subprotocol) {#les} This is a minimal protocol for syncing light clients. Traditionaly this protocol has rarely been used because full nodes are required to serve data to light clients without being incentivized. The default behaviour of execution clients is not to serve light client data over les. More information is available in the les [spec](https://github.com/ethereum/devp2p/blob/master/caps/les.md). -#### Snap {snap} +#### Snap {#snap} The [snap protocol](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) is an optional extension that allows peers to exchange snapshots of recent states, allowing peers to verify account and storage data without having to download intermediate Merkle trie nodes. -#### Wit (witness protocol) {wit} +#### Wit (witness protocol) {#wit} The [witness protocol](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) is an optional extension that enables exchange of state witnesses between peers, helping to sync clients to the tip of the chain. -#### Whisper {whisper} +#### Whisper {#whisper} This was a protocol that aimed to deliver secure messaging between peers without writing any information to the blockchain. It was part of the DevP2p wire protocol but is now deprecated. Other [related projects](https://wakunetwork.com/) exist with similar aims. -## Execution layer networking after the merge {execution-after-merge} +## Execution layer networking after the merge {#execution-after-merge} After the merge, an Ethereum node will run an execution client and a consensus client. The execution clients will operate similary to today, but with the proof-of-work consensus and block gossip functionality removed. The EVM, validator deposit contract and selecting/executing transactions from the mempool will still be the domain of the execution client. This means execution clients still need to participate in transaction gossip so that they can manage the transaction mempool. This requires encrypted communication between authenticated peers meaning the networking layer for consensus clients will still be a critical component, includng both the discovery protocol and DevP2P layer. Encoding will continue to be predominantly RLP on the execution layer. -## The consensus layer {consensus-layer} +## The consensus layer {#consensus-layer} The consensus clients participate in a separate peer-to-peer network with a different specification. Consensus clients need to participate in block gossip so that they can receive new blocks from peers and broadcast them when it is their turn to be block proposer. Similarly to the execution layer, this first requires a discovery protocol so that a node can find peers and establish secure sessions for exchanging blocks, attestations etc. -### Discovery {consensus-discovery} +### Discovery {#consensus-discovery} Similarly to the execution clients, consensus clients use [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) over UDP for finding peers. The consensus layer implementation of discv5 differs from that of the execution clients only in that it includes an adaptor connecting discv5 into a [libP2P](https://libp2p.io/) stack, deprecating devP2P. The execution layer's RLPx sessions are deprecated in favour of libP2P's noise secure channel handshake. -### ENRs {consensus-enr} +### ENRs {#consensus-enr} The ENR for consensus nodes includes the node's public key, IP address, UDP and TCP ports and two consensus-specific fields: the attestation subnet bitfield and eth2 key. The former makes it easier for nodes to find peers participating in specific attestation gossip sub-networks. The eth2 key contans information about which Ethereum fork version the node is using, ensuring peers are connecting to the right Ethereum. -### libP2P {libp2p} +### libP2P {#libp2p} The libP2P stack supports all communications after discovery. Clients can dial and listen on IPv4 and/or IPv6 as defined in their ENR. The protocols on the libP2P layer can be subdivided into the gossip and req/resp domains. -### Gossip {gossip} +### Gossip {#gossip} The gossip domain includes all information that has to spread rapidly throughout the network. This includes beacon blocks, proofs, attestations, exits and slashings. This is transmitted using libP2P gossipsub v1 and relies on various metadata being stored locally at each node, including maximum size of gossip payloads to receive and transmit. Detailed information about the gossip domain is available [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). -### Req/Resp {req-resp} +### Req/Resp {#req-resp} The request/response domain contains protocols for clients requesting specific information from their peers. Examples include requesting specific Beacon blocks matching certain root hashes or within a range of slots. The responses are always returned as snappy-compressed SSZ encoded bytes. -## Why does the consensus client prefer SSZ to RLP? {ssz-vs-rlp} +## Why does the consensus client prefer SSZ to RLP? {#ssz-vs-rlp} SSZ stands for simple serialization. It uses fixed offsets that make it easy to decode individual parts of an encoded message without having to decode the entire structure, which is very useful for the consensus client as it can efficiently grab specific pieces of information from encoded messages. It is also designed specifically to integrate with Merkle protocols, with related efficiency gains for Merkleization. Since all hashes in the consensus layer are Merkle roots, this adds up to a significant improvement. SSZ also guarantees unique representations of values. -## Connecting the execution and consensus clients +## Connecting the execution and consensus clients {#connecting-clients} After the merge, both consensus and execution clients will run in parallel. They need to be connected together so that the consensus client can provide instructions to the execution client and the execution client can pass bundles of transactions to the consensus client to include in Beacon Blocks. This communication between the two clients can be achieved using a local RPC connection. Since both clients sit behind a single network identity, they share a ENR (Ethereum node record) which contains a separate key for each client (eth1 key and eth2 key). @@ -147,7 +147,7 @@ Once the block has been attested by sufficient validators it is added to the hea Network layer schematic for post-merge consensus and execution clients, from [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)

-## Further Reading +## Further Reading {#further-reading} [DevP2p](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) diff --git a/src/intl/en/page-developers-index.json b/src/intl/en/page-developers-index.json index f58687a2cda..6350f93c146 100644 --- a/src/intl/en/page-developers-index.json +++ b/src/intl/en/page-developers-index.json @@ -86,6 +86,6 @@ "page-developers-web3-desc": "How the web3 world of development is different", "page-developers-web3-link": "Web2 vs Web3", "page-developers-networking-layer": "Networking Layer", - "page-developers-data-structures-link": "Networking Layer", - "page-developers-data-structures-desc": "Introduction to the Ethereum networking layer" + "page-developers-networking-layer-link": "Networking Layer", + "page-developers-networking-layer-desc": "Introduction to the Ethereum networking layer" } From 1fb4e468a31f963ef9833b73b38814085ebddb0a Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 30 Mar 2022 13:40:00 +0100 Subject: [PATCH 07/31] fix image links (html ->markdown) --- src/content/developers/docs/networking-layer/index.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 16323368fc8..ef384a49bd6 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -139,13 +139,10 @@ A summary of the control flow is shown beloiw, with the relevant networking stac Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalised. -

- -

- +![](./cons_client_net_layer.png) +![](./exe_client_net_layer.png) Network layer schematic for post-merge consensus and execution clients, from [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) -

## Further Reading {#further-reading} From 64d75fd9903e65a00db66ef42f2be1cde2e7ef7e Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 30 Mar 2022 13:51:19 +0100 Subject: [PATCH 08/31] remove redundant image --- .../exe_cons_client_net_layer.png | Bin 7492 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 src/content/developers/docs/networking-layer/exe_cons_client_net_layer.png diff --git a/src/content/developers/docs/networking-layer/exe_cons_client_net_layer.png b/src/content/developers/docs/networking-layer/exe_cons_client_net_layer.png deleted file mode 100644 index 0fa59d88dd1b1b7c276e8a69c772340737744220..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 7492 zcmb7}2T)T@yZ8eL_zEJgH0dZ+31A3CI*K% zfJj1bp-Tuzm)`Lo?|bje_s##_xpQaEw&&S-&Ys<~yU%Yo)<945@+FQ-AQ0%Xw$}Ye zAP@zH9C|O31t3}ZhWj88H=XwVyGDK!>(haLMxM&CeE% zf1v^bDRNyibcIYfKpKg%*8xWq;rq#3ymH98c!8Le9ouM%Op);6maUQZz6*sFFF|Nx z{P`}kZVc=ez&q92UUMvxeEObJc4O^J)B0>41R>mQ9~uKYslQvNB0U0g3l8_5q9l1# zRh)*iKwk&8&|A36>(tx?pC1jDp~g0h@b$_BPSmSxlNY;(Q|u2Us~CDtp5Go#B|L{fnwiwI|Y2mB=?{Yv=crZX5b4JbL|-{CHA{ z7Uy?`BkiL3#aGGiPMj3=Q|T?jo6k;phc6TQHL~ZEvifOALFd+y^CsDhm<9Zk4@nCJ zjZ?bW^8i~}&^tQT-_M}ggPMcpuo=zm=Vm1vhc4r+#?GP!6-hoPhDut;RpxVaS?anD zUspdnMlC78iwQWIG%Oqj5`5|_+buq8%8%o z!|cwS3N6j9#Vqj2V5eD7{l(sCF07bgJnPq|D20#vi>pbr_|e>_qs&dD0?#YI_8PsG ztWG}7Ucjg48C2wh#$H@=sufjSp~lPeGfgndcC$hrPOts#!rz^AKy?>WCyd$)+CO63 zd3|LnpL^Y;EJz@^ZJhzt7+%M9+cjBvyKE;djCO-AG0~7I4mJT)eVyl@Rm1YRKCsq- z`h<+C4Vor$KP}*qDCL%Pk#XqUc&{=ivfz?g zjqq1*Ll!-IF^XXX$)vsb+wYN*?2j+^RJ6}8zJbO(>Tj1-5?@r-lR`JylW%q znp@`*1=5PXKS}8{g*<`=xy97YBSIbEA}`Zuc@^WfjUa0VL6^CX=#%i0w*h+o424T` zC9QXuG>ixL92t+qIzzAjnS*ele^36A{cHTc=zSmUy0tFHIoflsQ3J#tycf?bLJDdM z;3k$R8azM0JxSbq+pggLK9@!ZX2%CzN~Pm~+WP*anQQvJ0bRWKap_IfTX-4-m-A4F z>f3#lK+LXa{1r~WHfD#$Yjnpx?u$<(*+I{=Y4+_`J&x`cmN1DL1{sY3mByJ-zF!iT zvz6lfgQQ-Z2A|gI?>UbKz>MY>9!$FMv$EWupRtl5Mg*Ur%C}M(34)GG$F7K~eYVbl z(WIfp<$#byr_*Mn8e$L#Pm|cN3+tdkkNGgngE`rp9dstvAl}Tq{)rQ98$%dW$>M7> zHAD@NpN*#W7I$*rI+IsXZWie5N1_S3h$}3w*h6mb7qsFz5cG-KS$ml;+FpG-q{vtv z#x>r@tHJ*WU9oi3cAagxMfy;CSm{Jtv23xkufB)AEovGzKT?RopoiJHxGa~mg34c=&43KiZm@@Fy8-KpFLJ6Hr5^Lh(v@Eemc$a}lt!u~aztJA^N6_G&S%;zae*FCj zC6~)CgJDCm`+Pj^t+@#Yz!p+8s94f zfkqJK91l|UK#9FIkCKt>pA$?^p#+f4lP7=LIJg!qXr)IP>QVLW9LEQ!e2wm%vwM|U z8Gvb(HVj$~;LbV<(5`9}KLvj~Upz56J$)DLxMyn2bzlNJ^~nDAiLhZO%JV{Oc_&(8 zE;s6Zxv8n(L`fZdJ75|mO|%RU{mPMVN(r*!HZ1@6$m75S#}PMqzZaiJ4H_0Y@$qMw z6jH~zc?sqe(0Gh&1N#bVaVz$%PQ$#)O*F;H(PP_LEV6+~Soa%az@+WOF{$$VLY}L} zwkw)Gp2ZPmFKTdAQ)~>#SFvzzTv9t8#dVF~t#%UEKlX~uGTP{?*Co?iB&*P_)>+Hi zcTUqTON+YAHtmJ|ir7_}sr|jt2+gB=ue;E>wjRB&sDyD+zj8#^qF2N1qn08mHV_#? z0ZO0XOXBM|$TL0J|=2ewy;vCjfj%_dB%dx?4M^ z90#X)s0yZvLq+IB`#-i;BUCYauIw65*66G6H_xvzt)bXz7l+VvV`bBhZ07wMRfJ(( z26A_5@Bij{GaW(IqvdN_Nsm$&+Rf69?*9A$i_b8q!i5new0TTcqO@wh(v#X_YVLb* zArr2Sly|y)Y}RU8D>+6in}JjzLeiwV{5lY8JeIPS8ZW*}vqSG0PuX(Eg_GKgv5GLC ztn*X4Z#yLnDryBim8~vhRPsiw3vhiSu&=91P=2eUcE^^=fS&p8q|kv*0)K`x zW_@Mupu3rhA4e%;w4OY(R3+&DE?DgwSkjgUKgHssb`olT#{a#x_LpW0m(DIl&c?tX zJ`NsFnpnI2y;=LYpfa4!R~^-8;GtMH6Np^C9unts9rG>XE6$gMLytaGj%;p_l5)~~ z?HD@?KRBI#Mk85yJteC|D$lIfD@Y-IDbMsnf=g%4>* z9C79WcG}!=OY_fX=z3t-y<`@^?m0WoqWz?D2Dd%uvmcVWJFw{FY(^Yam%b9ettLj_ zaj@s8vpo&;;YExKEwD$PWh-*(nm;+ODRPd4@PbIW-;O$eMSR92*T)gb6)uy$xkOQl zDEySxL{axhVG%z`7eFG_@>-@}W)WP&19I@^B@aIh_{||V(`nz(s>DNW1+Ge^Xk(JX z&cv<1)EsW{E~SjZ3oh&}CogTACoFOac)(7PO`+Z(bra__B>Pu1XSuc>hzn%~K!z9< zDpd+f!EP=czf)`BlvuDP;Mi3`JQd*nP)0lcutVoJVErjh09MA3czIdy20SCaaqTno zmdP)Sw3rm62W!EaBUg|&eUZg1E$~Syk~D>O#%X8XXn2>uJh|3c)c|e6!87*mSk&AG zjshS<<*46f80C25nRKTcHvm{ZHiQ-Hzi3=WC`8%?GDytL`2DUau2;f>d!T;qF2<*; zM{7Kgp?pG5kzGFU0)+*~LmDm&DQg*Y@dE*pUbbpwZtt8Ee4y+menT>OKRBa<&i1NN@U~o6{)|fcgr|U4V_3_>hrH$aI1&xKIBi7# zMj$iv6S~!S(sdMGTyj8P|3C$rgIeoLa2&k_Xh5Au(qm#!l_u7Y_eFr?Cqbed9XJQM zn5gI95&|%!$UNDMX+xW*n$=DHc=2PmFqBUO?^&TR=J=RC3*S`Jj5!2Iw<$4-v<&-F4QTToY_DHUlu_?=_)MN@ykCVB`m-SH)l^22X>q2dhKi7bAt; zS(WTEv~Zk&V<-Dko(LDF2_yUJwXpFey!$=$>}`;`ee(8uX7HGX5Uox3VXG8c820zok+kKMqCRgyD@5} ziLMg#m`&!*f+RfGo)9wygr@5q-VZ&G&ZXv)`E|B1yPK2URB%~or_7&Knxj8dA2t^ zmC(bAO%FH2kofe!p`Po61{cD9l3TbVw?cpY)@*0t#@F=X-mXo1hSi9aa6}of+iGA= zsn(f(a!}N8w!NEOQg~Ah5J+yBXxYCTcq?UiS_Fa!Px|aRLZ-qn}Ejc9^xX|vb&(a*n1>t7HzzP zc-est#W`h>e<$FGU`F<*X(T7%{gdjN7!;Krgfj?84Zqf><9Wu_r2&EFz?kH*xMzSk zAwN+W+Rcg8!Cmd>>lXuPpw1DRIE{SN0$(RI&BD41XuYB`z7vZikwL~UI>`3|Z-j@J z`9k=SY;fvSF{nK!2%cdNRfr04`)hW!<>t!Qb&74__Jl58qtNGeA;q#7X#v7-0pM~q zwWv13r=o)JDhhM$ zQ{U&Uo5=2UgLswZFVp3l*RbF!;BpZ^o^^9|ZOz-rMv(Aw@(QowxLf%A#+SNax#H1s z*zNSs@2{8>BIVn-9BZAvM?hS!9g2HOS{35GG8DNAC@?V-0f* zU*Ie3*YOM@%Pv4n$W^0?{-dVys3opLhy3URRuE_^Dq29v@4hD^5jg@rh_KRMFLQrw zF?$ivMKo_RxyA$8~jm7s~5TkC-HBBW>* z-vM6Y#y^1cM8h^0vn!FlG6^jI9lWjI?6?uwI^WCbR6_CCg#8t4eTR)Ljuh#CbXIQZw-CzNydQ&77g`*?mu7m3#K zms#veVUvtkMUzx5lbg=$njvnr@CWgLSQ1objT!BEdsWzU0^qEUiDX>2gX;bKnBT}D z@mGpvs&D12%)V2|U8F~ss=ifxs|*x}#sN6KCd6e1c#2YA5^=Wq0!2;)9;stlbUDmhP0# z&C7v>bRW>gCh*#z^zb{!kV%5Q16LTPgY&LG*5%kh zFk)Wzabm&QRAdDn2OAXtIwglvA#tcmTy0t`$_-cS(7Izx<~XSw7!Bgf!ZN0+@hESR z3Z5~&m!I00?UpfRps@1=1IqcmsiM0QTsjwd0bcBp=p;Ek|7r)7jl&|Fj(Y?KuVf-g zLkR-@^H+9ko_HFFq8=Z^&hc8l7N(E3%~aK}SpwZ1XrVyY5bw!lOtL`bqW1ol3_Jrr zdZ4Ggl$<`>=E`Dx9c(* z(mN)Z28o09;tu(I(*(Ftd`y@eB)1Y#FLi-A^SJRQwHDj#_NC%+(n>eKEIm=G&J~~y!vGV zD&Q^8tDuBH^?iF9$O*f$H;qJii}y%&taY`6WtAw@T4GsxOkIh(<~Qn~R(GYM=5WWg zK9CScYyI%}^aq_^$@P_$5#!i>#|mVNl_r4q%bfZCGqH_Zv`%-z9O5j}2lP>boYI0~ zNaf=)H{rh7qCYN3$CPK#VrFeky;W8x2^Y~LcU=3b6_XSH9oG_G{THo0{~u_LZ}+97Tbd`Is9uqq&$V(CXy! z%M1FwZGoocZWa5UW+Ro4+KNNt{z8Bil=U<+M0NU=`Db8%ivAx^+kP*DaT%pNMFou< zLJ0bU2Ow6Ox8J4kKU-`M`fH<%^tQT?HhnDx(kg&uLxzCsIF_|`z*)v8EgZmBxTV$! zkL~;?lAS3`=?+@{ElKxUvkv8hu})P)zqhVtfTmONf4_?Lu#tT5vKiVuy>Vl?CVwTl z2tfhDB8SsUf=4OMz^rurtWwSW4+HdN;)i##?2o>+!?DvZWwktQzkwg|xItHeW~~4` z$!+@=cl(su*Pg3gnhjhchRwbAb%m?eJUTq>_c?7oPc?e6jrv@`gU^vbN`Mo~1oOux zAIh-^+&z+^D=>{t{EQ7^GN?}$8Di8M2QgEr_t$qTF%e@(y)MmJ+#%Z=?WOn|dpBh8 zez8y8Nm`iqGG6e-%J-ZTw2G^|hQ&pZD)V+eHekwUQJN2BMdQRW6fj>!Hif2NAI6A{ zv&@1YNx*kxZYeG#Lk7WRcy#tiKzGSAw#@lV;s1uo82&#doAA*xBR!MvEc6|YjJI0%g50g=#}a4WBL z*aw}*icwa2pwO%3;ogF$N}YEtbNGFqHw{yjh9Q)7_wGSHEL{wwQhV)l-r<9>8-;wB zB|S7_RXHar4nCnzFHk<)aiuvFD`sNRWcRyR53bGCVMuKN2kTg>%7@-4uX8j)QZG`` zi59$oTVUMKLUI((p2AUyzq0LTp-|g;dy=m71kTqYMD;OjYCPt*pdXVcIj{i_{Payxt4Zt6AvSKXI{m93`MN8uEzcCg#yDNEy)i3ia9N)yk#20JkboO?i z92!hyO%0`zcVxg4p(k%lObsq}$8fgI_x_ZOhm8`Sb$>yUR_ zb60gv`0jF(Pu99|(%iETy`fP{HDn%4B($oRB%k=tJ9XQWtrbOm9AQm#@83H1=5%o z<+Jzd?Av!rIkP|uQFTra?sw>zmRH>*!(C8CE6Zi_0Vdb|uL@5!J`uL>^>OxWh}^Cz zG_(8(umyc=$I1VC%Ya{5g_3>x@08F$?nxhq48A~}-nIQfRa=yjp|?&nVCYccnEff@ z&vHiU9r&af&GtvCmv@&<6Mpdr@|p4arQ#VyV^YL+)Mn zanTTMW$3uZl_pK(b`Vd$u&~*8YBmPsB;NQVl;Lc0atX9W29@~H`nW8`|HY*^0h!|5*J;;N z|J<8XXO)cKiN9rdd`dsDiSV}N%b}Sx7?Mh}22Sp|{zcFJcw;tme!pkPJuj)49+jfF z?X)vNyB-xM99(_0J}jGeJ*0$(^zSzW|5^IiD};aY|6c8X)BhjL$U&Pu8zVaV6HyWS e{n3QqR4sGPH!R)_qW@fvYOCwrue@jT^8W$a=g>(2 From 20b2950b887180900f32d82a26ef79e968a68a26 Mon Sep 17 00:00:00 2001 From: Joe Date: Wed, 30 Mar 2022 13:52:25 +0100 Subject: [PATCH 09/31] fix page section links --- .../docs/networking-layer/network-addresses/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 3df7d844828..770f2d3a379 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -12,7 +12,7 @@ Ethereum nodes have to identify themselves with some basic information so that t Some understanding of Ethereum's [networking layer](/src/content/developers/docs/networking-layer/) will be helpful to understand this page. -## Multiaddr {multiaddr} +## Multiaddr {#multiaddr} The original network address format was the "multiaddr". This is a universal format not only designed for Ethereum nodes but other peer-to-peer networks too. Addresses are represented as key-value pairs with keys and values separated with a forward slash, e.g. the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: @@ -22,7 +22,7 @@ For an Ethereum node, the multiaddr has the node-ID (hash of their public key), `/ip6/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` -## Enode {enode} +## Enode {#enode} An ethereum node can also be described using the enode URL scheme. The hexadecimal node-ID is encoded in the username portion of the URLseparated from the host using an @ sign. The hostname can only be given as an IP address, DNS nammes are not allowed. The port in the host name section is the TCP listening port. If the TCP and UDP (discovery) ports differ the UDP port is specified as a query parameter "discport". @@ -30,11 +30,11 @@ In the following example, the node URL describes a node with IP address `10.3.58 `enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` -## Ethereum Node Records (ENRs) {enr} +## Ethereum Node Records (ENRs) {#enr} Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddresses and enodes. These are especially useful because they allow greater informational exchange between nodes. The ENR contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures. The rest of the record can be populated with arbitrary data organised as key-value pairs. These key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use. Consensus clients use a [specific ENR structure](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) to identify boot nodes and also include an `eth2` field containing information about the current Ethereum fork and the attestation gossip subnet (this connects the node to a particular set of peers whose attestations are aggregated together). -## Further Reading +## Further Reading {#further-reading} [ENR EIP](https://eips.ethereum.org/EIPS/eip-778) [Network addresses in Ethereum](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) From a9f7f921d17599d245181c44a69cca56d6d9f3e7 Mon Sep 17 00:00:00 2001 From: Joe Date: Thu, 31 Mar 2022 11:29:04 +0100 Subject: [PATCH 10/31] rm notes accidentally committed & + to gitignore --- development-notes.md | 75 -------------------------------------------- 1 file changed, 75 deletions(-) delete mode 100644 development-notes.md diff --git a/development-notes.md b/development-notes.md deleted file mode 100644 index 1d80e3d8b3d..00000000000 --- a/development-notes.md +++ /dev/null @@ -1,75 +0,0 @@ -To add a new page to ethereum.org: - -If the new page needs a new directory, create it and also create a landing page named index.md -Then create a subdir for the specific page, inside create the content file index.md. - -e.g. new dir in /developer/docs/ - -``` -developers -| -|---- docs - | - |----data-structures - | - |----index.md - |----rlp - | - |----index.md - -``` - -`data-structures/index.md` is a landing page with links to the content in its subdirectories but usually containing some introductory information about the topic. -The specific content about (e.g.) rlp serialization goes in `/data-structures/rlp/index.md`. - -Then this page needs to be made visible in the top menu and sidebar menu. This requires additions to four files. - -1. /src/data/developers-docs-links.yaml - -This file includes links that are used to automatically update links to translated pages. Copy the syntax from other pages, nesting where appropriate - -e.g. - -```yaml - ---- -- id: docs-nav-data-structures - to: /developers/docs/data-structures/ - description: docs-nav-data-structures-description - items: - - id: docs-nav-data-structures-rlp - to: /developers/docs/data-structures/rlp/ -``` - -2. src/intl/en/page-developers-docs.json - -This adds info necessary for including the pages in menus. Copy syntax from othe rpages and add for new page. -e.g. - -```yaml -... - "docs-nav-data-structures": "Data structures", - "docs-nav-data-structures-description": "Explanation of the data structures used across the Ethereum stack", - "docs-nav-data-structures-rlp": "Recursive-length prefix (RLP)", - -``` - -3. src/intl/en/page-developers-index.json - -```yaml - -``` - -4. src/pages/developers/index.js - Adds link to the developers landing page - -```yaml - ---- - - - -

- -

-``` From add5f4336c867559b251fa082f2df6982f7688ab Mon Sep 17 00:00:00 2001 From: Joe Date: Thu, 31 Mar 2022 11:29:23 +0100 Subject: [PATCH 11/31] update img link --- src/content/developers/docs/networking-layer/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index ef384a49bd6..269c0cea36b 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -139,8 +139,8 @@ A summary of the control flow is shown beloiw, with the relevant networking stac Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalised. -![](./cons_client_net_layer.png) -![](./exe_client_net_layer.png) +![](cons_client_net_layer.png) +![](exe_client_net_layer.png) Network layer schematic for post-merge consensus and execution clients, from [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) From fe7a497790be222e25c3769d23807ca6faea5a32 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 5 Apr 2022 13:37:54 +0100 Subject: [PATCH 12/31] Update src/content/developers/docs/networking-layer/network-addresses/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 770f2d3a379..44482cdba07 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -6,7 +6,7 @@ sidebar: true sidebarDepth: 2 --- -Ethereum nodes have to identify themselves with some basic information so that they can connect to peers. To ensure this information can be interpreted by any potential peer it is relayed in one of three standardized formats that any Ethereum node can understand: multiaddr, enode and Ethereum Node Records. +Ethereum nodes have to identify themselves with some basic information to connect to peers. To ensure any potential peer can interpret this information, it is relayed in one of three standardized formats that any Ethereum node can understand: multiaddr, enode, or Ethereum Node Records. ## Prerequisites {#prerequisites} From a68156ff691f7934c41b5b35d17f400cb80b7b92 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 5 Apr 2022 13:40:09 +0100 Subject: [PATCH 13/31] Update src/content/developers/docs/networking-layer/network-addresses/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 44482cdba07..8e54e3cf17a 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -14,7 +14,7 @@ Some understanding of Ethereum's [networking layer](/src/content/developers/docs ## Multiaddr {#multiaddr} -The original network address format was the "multiaddr". This is a universal format not only designed for Ethereum nodes but other peer-to-peer networks too. Addresses are represented as key-value pairs with keys and values separated with a forward slash, e.g. the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: +The original network address format was the 'multiaddr'. Multiaddr is a universal format designed for peer-to-peer networks. Addresses are represented as key-value pairs with keys and values separated with a forward slash. For example, the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: `/ip6/192.168.22.27/tcp/33000` From cdc9548334587f5bec232d34cb1d5677b3613e0e Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 5 Apr 2022 13:40:30 +0100 Subject: [PATCH 14/31] Update src/content/developers/docs/networking-layer/network-addresses/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 8e54e3cf17a..bc0eed8fb09 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -18,7 +18,7 @@ The original network address format was the 'multiaddr'. Multiaddr is a universa `/ip6/192.168.22.27/tcp/33000` -For an Ethereum node, the multiaddr has the node-ID (hash of their public key), for example: +For an Ethereum node, the multiaddr contains the node-ID (a hash of their public key): `/ip6/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` From 59e2af7b1025612f40de5f29675a3a6e29b0e74e Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 5 Apr 2022 13:44:46 +0100 Subject: [PATCH 15/31] Update src/content/developers/docs/networking-layer/network-addresses/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index bc0eed8fb09..af3b76243ca 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -24,7 +24,7 @@ For an Ethereum node, the multiaddr contains the node-ID (a hash of their public ## Enode {#enode} -An ethereum node can also be described using the enode URL scheme. The hexadecimal node-ID is encoded in the username portion of the URLseparated from the host using an @ sign. The hostname can only be given as an IP address, DNS nammes are not allowed. The port in the host name section is the TCP listening port. If the TCP and UDP (discovery) ports differ the UDP port is specified as a query parameter "discport". +An Ethereum node can also be described using the enode URL scheme. The hexadecimal node-ID is encoded in the username portion of the URL separated from the host using an @ sign. The hostname can only be given as an IP address; DNS names are not allowed. The port in the hostname section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as a query parameter "discport" In the following example, the node URL describes a node with IP address `10.3.58`, TCP port `30303` and UDP discovery port `30301`. From 7e410dd49b2e3822b8ad822c423ec090beffd2cf Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 5 Apr 2022 13:49:48 +0100 Subject: [PATCH 16/31] Update src/content/developers/docs/networking-layer/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- src/content/developers/docs/networking-layer/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 269c0cea36b..de448a4dde6 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -20,7 +20,7 @@ The execution layer's networking protocols can be divided into two stacks: the f Discovery is the process of finding other nodes in network. This is bootstrapped using a small set of bootnodes that are [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) into the client. These bootnodes exist to introduce a new node to a set of peers - this is their sole purpose, they do not participate in normal client tasks like syncing the chain, and they are only used the very first time a client is spun up. -The protocol used for the node-bootnode interactions is a modified form of [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) which uses a distributed hash table to share lists of nodes. Each node has a version of this table containing information required to connect to its closest peers. This "closeness" is not geographical - distance is defined by the similarity of the node's ID. Each node's table is regularly refreshed as a security feature. In the [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) discovery protocol nodes are also able to send "ads" that display the subprotocols that client supports, allowing peers to negotiate about the protocols they can both use to communicate over. +The protocol used for the node-bootnode interactions is a modified form of [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) which uses a distributed hash table to share lists of nodes. Each node has a version of this table containing the information required to connect to its closest peers. This 'closeness' is not geographical - distance is defined by the similarity of the node's ID. Each node's table is regularly refreshed as a security feature. For example, in the [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), discovery protocol nodes are also able to send 'ads' that display the subprotocols that the client supports, allowing peers to negotiate about the protocols they can both use to communicate over. Discovery starts wih a game of PING-PONG. A successful PING-PONG "bonds" the new node to a boot node. The initial message that alerts a boot node to the existence of a new node entering the network is a `PING`. This `PING` includes hashed information about the new node, the boot node and an expiry time-stamp. The boot node receives the PING and returns a `PONG` containing the `PING` hash. If the `PING` and `PONG` hashes match then the connection between the new node and boot node is verified and they are said to have "bonded". From 8c18b868b58c71c8db5dc104c47964048217e3ea Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 5 Apr 2022 14:02:28 +0100 Subject: [PATCH 17/31] udpate according to @minimalsm review comments --- .../developers/docs/networking-layer/index.md | 12 ++++++------ .../docs/networking-layer/network-addresses/index.md | 4 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index de448a4dde6..53c4e391760 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -14,22 +14,22 @@ Some knowledge of Ethereum [nodes and clients](/src/content/developers/docs/node ## The Execution Layer {#execution-layer} -The execution layer's networking protocols can be divided into two stacks: the first is the discovery stack which is built on top of UDP and allows a new node to find peers to connect to. The second is the [DevP2P](https://github.com/ethereum/devp2p) stack that sits on top of TCP and allows nodes to exchange information. These layers act in parallel, with the discovery layer feeding new network participants into the network, and the DevP2P layer enabling their interactions. DevP2P is itself a whole stack of protocols that are implemented by Ethereum to establish and maintain the peer-to-peer network. +The execution layer's networking protocols can be divided into two stacks: the first is the discovery stack which is built on top of UDP and allows a new node to find peers to connect to. The second is the [DevP2P](https://github.com/ethereum/devp2p) stack that sits on top of TCP and allows nodes to exchange information. These stacks act in parallel, with the discovery stack feeding new network participants into the network, and the DevP2P stack enabling their interactions. DevP2P is itself a whole stack of protocols that are implemented by Ethereum to establish and maintain the peer-to-peer network. ### Discovery {#discovery} -Discovery is the process of finding other nodes in network. This is bootstrapped using a small set of bootnodes that are [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) into the client. These bootnodes exist to introduce a new node to a set of peers - this is their sole purpose, they do not participate in normal client tasks like syncing the chain, and they are only used the very first time a client is spun up. +Discovery is the process of finding other nodes in network. This is bootstrapped using a small set of bootnodes (nodes whose addresses are [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) into the client so they can be found immediately and connect the client to peers). These bootnodes only exist to introduce a new node to a set of peers - this is their sole purpose, they do not participate in normal client tasks like syncing the chain, and they are only used the very first time a client is spun up. The protocol used for the node-bootnode interactions is a modified form of [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) which uses a distributed hash table to share lists of nodes. Each node has a version of this table containing the information required to connect to its closest peers. This 'closeness' is not geographical - distance is defined by the similarity of the node's ID. Each node's table is regularly refreshed as a security feature. For example, in the [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), discovery protocol nodes are also able to send 'ads' that display the subprotocols that the client supports, allowing peers to negotiate about the protocols they can both use to communicate over. -Discovery starts wih a game of PING-PONG. A successful PING-PONG "bonds" the new node to a boot node. The initial message that alerts a boot node to the existence of a new node entering the network is a `PING`. This `PING` includes hashed information about the new node, the boot node and an expiry time-stamp. The boot node receives the PING and returns a `PONG` containing the `PING` hash. If the `PING` and `PONG` hashes match then the connection between the new node and boot node is verified and they are said to have "bonded". +Discovery starts wih a game of PING-PONG. A successful PING-PONG "bonds" the new node to a bootnode. The initial message that alerts a bootnode to the existence of a new node entering the network is a `PING`. This `PING` includes hashed information about the new node, the bootnode and an expiry time-stamp. The bootnode receives the PING and returns a `PONG` containing the `PING` hash. If the `PING` and `PONG` hashes match then the connection between the new node and bootnode is verified and they are said to have "bonded". -Once bonded, the new node can send a `FIND-NEIGHBOURS` request to the boot node. The data returned by the boot node includes a list of peers that the new node can connect to. If the nodes are not bonded, the `FIND-NEIGHBOURS` request will fail, so the new node will not be able to enter the network. +Once bonded, the new node can send a `FIND-NEIGHBOURS` request to the bootnode. The data returned by the bootnode includes a list of peers that the new node can connect to. If the nodes are not bonded, the `FIND-NEIGHBOURS` request will fail, so the new node will not be able to enter the network. -Once the new node receives a list of neighbours from the boot node, it begins a PING-PONG exchange with each of them. Successful PING-PONGs bond the new node with its neighbours, enabling message exchange. +Once the new node receives a list of neighbours from the bootnode, it begins a PING-PONG exchange with each of them. Successful PING-PONGs bond the new node with its neighbours, enabling message exchange. ``` -start client --> connect to boot node --> bond to boot node --> find neighbours --> bond to neighbours +start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours ``` #### ENR: Ethereum Node Records {#enr} diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index af3b76243ca..7fba902c302 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -14,7 +14,7 @@ Some understanding of Ethereum's [networking layer](/src/content/developers/docs ## Multiaddr {#multiaddr} -The original network address format was the 'multiaddr'. Multiaddr is a universal format designed for peer-to-peer networks. Addresses are represented as key-value pairs with keys and values separated with a forward slash. For example, the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: +The original Ethereum node address format was the 'multiaddr'. Multiaddr is a universal format designed for peer-to-peer networks. Addresses are represented as key-value pairs with keys and values separated with a forward slash. For example, the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: `/ip6/192.168.22.27/tcp/33000` @@ -24,7 +24,7 @@ For an Ethereum node, the multiaddr contains the node-ID (a hash of their public ## Enode {#enode} -An Ethereum node can also be described using the enode URL scheme. The hexadecimal node-ID is encoded in the username portion of the URL separated from the host using an @ sign. The hostname can only be given as an IP address; DNS names are not allowed. The port in the hostname section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as a query parameter "discport" +An enode is a way to identify an Ethereum node using a URL address format. The hexadecimal node-ID is encoded in the username portion of the URL separated from the host using an @ sign. The hostname can only be given as an IP address; DNS names are not allowed. The port in the hostname section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as a query parameter "discport" In the following example, the node URL describes a node with IP address `10.3.58`, TCP port `30303` and UDP discovery port `30301`. From bf4c4070e7453f4f40da07598db4ff1c37fb0a16 Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 5 Apr 2022 14:07:09 +0100 Subject: [PATCH 18/31] DevP2P info to DevP2P section, move link --- src/content/developers/docs/networking-layer/index.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 53c4e391760..785d82388d3 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -14,7 +14,13 @@ Some knowledge of Ethereum [nodes and clients](/src/content/developers/docs/node ## The Execution Layer {#execution-layer} -The execution layer's networking protocols can be divided into two stacks: the first is the discovery stack which is built on top of UDP and allows a new node to find peers to connect to. The second is the [DevP2P](https://github.com/ethereum/devp2p) stack that sits on top of TCP and allows nodes to exchange information. These stacks act in parallel, with the discovery stack feeding new network participants into the network, and the DevP2P stack enabling their interactions. DevP2P is itself a whole stack of protocols that are implemented by Ethereum to establish and maintain the peer-to-peer network. +The execution layer's networking protocols is divided into two stacks: + +- the discovery stack: built on top of UDP and allows a new node to find peers to connect to + +- the DevP2P stack: sits on top of TCP and enables nodes to exchange information + +Both stacks work in parallel. The discovery stack feeds new network participants into the network, and the DevP2P stack enables their interactions. ### Discovery {#discovery} @@ -42,7 +48,7 @@ UDP does not support any error checking, resending of failed packets, or dynamic ## DevP2P {#devp2p} -After new nodes enter the network, their interactions are governed by protocols in the DevP2P stack. These all sit on top of TCP and include the RLPx transport protocol, wire protocol and several sub-protocols. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) is the protocol governing initiating, authenticating and maintaining sessions between nodes. RLPx encodes messages using RLP (Recursive Length Prefix) which is a very space-efficient method of encoding data into a minimal structure for sending between nodes. +DevP2P is itself a whole stack of protocols that Ethereum implements to establish and maintain the peer-to-peer network. After new nodes enter the network, their interactions are governed by protocols in the [DevP2P](https://github.com/ethereum/devp2p) stack. These all sit on top of TCP and include the RLPx transport protocol, wire protocol and several sub-protocols. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) is the protocol governing initiating, authenticating and maintaining sessions between nodes. RLPx encodes messages using RLP (Recursive Length Prefix) which is a very space-efficient method of encoding data into a minimal structure for sending between nodes. A RLPx session between two nodes begins with an initial cryptographic handshake. This involves the node sending an auth message which is then verified by the peer. On successful verification, the peer generates an auth-acknowledgement message to return to the initiator node. This is a key-exchange process that enables the nodes to communicate privately and securely. A successful cryptographic handshake then triggers both nodes to to send a "hello" message to one another "on the wire". The wire protocol is initiated by a successful exchange of hello messages. From 27cf522d463232d13a4a851f5a111420a412c4b9 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 13 Apr 2022 11:51:51 +0100 Subject: [PATCH 19/31] update according to @minimalsm comments --- .../docs/networking-layer/network-addresses/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 7fba902c302..1ec0d2a789e 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -14,7 +14,7 @@ Some understanding of Ethereum's [networking layer](/src/content/developers/docs ## Multiaddr {#multiaddr} -The original Ethereum node address format was the 'multiaddr'. Multiaddr is a universal format designed for peer-to-peer networks. Addresses are represented as key-value pairs with keys and values separated with a forward slash. For example, the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: +The original Ethereum node address format was the 'multiaddr' (short for 'multi-addresses'). Multiaddr is a universal format designed for peer-to-peer networks. Addresses are represented as key-value pairs with keys and values separated with a forward slash. For example, the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: `/ip6/192.168.22.27/tcp/33000` @@ -32,7 +32,7 @@ In the following example, the node URL describes a node with IP address `10.3.58 ## Ethereum Node Records (ENRs) {#enr} -Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddresses and enodes. These are especially useful because they allow greater informational exchange between nodes. The ENR contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures. The rest of the record can be populated with arbitrary data organised as key-value pairs. These key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use. Consensus clients use a [specific ENR structure](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) to identify boot nodes and also include an `eth2` field containing information about the current Ethereum fork and the attestation gossip subnet (this connects the node to a particular set of peers whose attestations are aggregated together). +Ethereum Node Records (ENRs) are a standardized format for network addresses on Ethereum. They supercede multiaddr's and enodes. These are especially useful because they allow greater informational exchange between nodes. The ENR contains a signature, sequence number and fields detailing the identity scheme used to generate and validate signatures. The ENR can also be populated with arbitrary data organized as key-value pairs. These key-value pairs contain the node's IP address and information about the sub-protocols the node is able to use. Consensus clients use a [specific ENR structure](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) to identify boot nodes and also include an `eth2` field containing information about the current Ethereum fork and the attestation gossip subnet (this connects the node to a particular set of peers whose attestations are aggregated together). ## Further Reading {#further-reading} From a142f557f45b9711756d336a0d63eb4ae2c95d34 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 13 Apr 2022 11:54:54 +0100 Subject: [PATCH 20/31] Update index.md --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 1ec0d2a789e..4ef61c83161 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -6,7 +6,7 @@ sidebar: true sidebarDepth: 2 --- -Ethereum nodes have to identify themselves with some basic information to connect to peers. To ensure any potential peer can interpret this information, it is relayed in one of three standardized formats that any Ethereum node can understand: multiaddr, enode, or Ethereum Node Records. +Ethereum nodes have to identify themselves with some basic information to connect to peers. To ensure any potential peer can interpret this information, it is relayed in one of three standardized formats that any Ethereum node can understand: multiaddr, enode, or Ethereum Node Records (ENRs). ENRs are the current standard for Ethereum network addresses. ## Prerequisites {#prerequisites} From b0883078d2b8ba3e8fedf9c6f0598f4d7d233bfb Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 13 Apr 2022 11:55:12 +0100 Subject: [PATCH 21/31] Update src/content/developers/docs/networking-layer/network-addresses/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 4ef61c83161..a5ae6b46dc6 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -36,6 +36,6 @@ Ethereum Node Records (ENRs) are a standardized format for network addresses on ## Further Reading {#further-reading} -[ENR EIP](https://eips.ethereum.org/EIPS/eip-778) +[EIP-778: Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778) [Network addresses in Ethereum](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) From 0776144ffeacc9d550eb58c7918b5b2ba4ef8c58 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 13 Apr 2022 11:57:10 +0100 Subject: [PATCH 22/31] Update src/content/developers/docs/networking-layer/index.md Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> --- src/content/developers/docs/networking-layer/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 785d82388d3..24c11f7fd60 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -6,7 +6,7 @@ sidebar: true sidebarDepth: 2 --- -Ethereum's networking layer is the stack of protocols that allows nodes to find each other and exchange information. After the merge there will be two pieces of client software (execution clients and consensus clients) each with their own separate networking stack. As well as communicating with other nodes on the Ethereum network, the execution and consensus clients also have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication to take place. +Ethereum's networking layer is the stack of protocols that allows nodes to find each other and exchange information. After [The Merge](/upgrades/merge/), there will be two parts of client software (execution clients and consensus clients), each with its own distinct networking stack. As well as communicating with other Ethereum nodes, the execution and consensus clients have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication. ## Prerequisites {#prerequisites} From afc103fd1359c7f756be03c70d3a88d3fd25dc80 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 13 Apr 2022 11:59:31 +0100 Subject: [PATCH 23/31] Update index.md --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index a5ae6b46dc6..d12b0a4ab31 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -10,7 +10,7 @@ Ethereum nodes have to identify themselves with some basic information to connec ## Prerequisites {#prerequisites} -Some understanding of Ethereum's [networking layer](/src/content/developers/docs/networking-layer/) will be helpful to understand this page. +Some understanding of Ethereum's [networking layer](/src/content/developers/docs/networking-layer/) is required to understand this page. ## Multiaddr {#multiaddr} From 5f47efc1aedbf49e36e6da6634424f6e96c65cfd Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Wed, 13 Apr 2022 12:01:30 +0100 Subject: [PATCH 24/31] 2nd lev el heading -> 3rd level heading --- src/content/developers/docs/networking-layer/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 24c11f7fd60..8c5ef20be2b 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -46,7 +46,7 @@ The [Ethereum Node Record (ENR)](/developers/docs/networking-layer/network addre UDP does not support any error checking, resending of failed packets, or dynamically opening and closing connections - instead it just fires a continuous stream of information at a target, regardless of whether it is successfully received. This minimal functionality also translates into minimal overhead, making this kind of connection very fast. For discovery, where a node simply wants to make its presence known in order to then establish a formal connection with a peer, UDP is sufficient. However, for the rest of the networking stack, UDP is not fit for purpose. The informational exchange between nodes is quite complex and therefore needs a more fully featured protocol that can support resending, error checking etc. The additional overhead associated with TCP is worth the additional functionality. Therefore, the majority of the P2P stack operates over TCP. -## DevP2P {#devp2p} +### DevP2P {#devp2p} DevP2P is itself a whole stack of protocols that Ethereum implements to establish and maintain the peer-to-peer network. After new nodes enter the network, their interactions are governed by protocols in the [DevP2P](https://github.com/ethereum/devp2p) stack. These all sit on top of TCP and include the RLPx transport protocol, wire protocol and several sub-protocols. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) is the protocol governing initiating, authenticating and maintaining sessions between nodes. RLPx encodes messages using RLP (Recursive Length Prefix) which is a very space-efficient method of encoding data into a minimal structure for sending between nodes. From 1fd8aa33fc9d18be02520e11df440d04de9c9ad9 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 10 May 2022 12:16:44 +0100 Subject: [PATCH 25/31] add to intro paragraph --- src/content/developers/docs/networking-layer/index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 8c5ef20be2b..cf2da81fe86 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -6,7 +6,9 @@ sidebar: true sidebarDepth: 2 --- -Ethereum's networking layer is the stack of protocols that allows nodes to find each other and exchange information. After [The Merge](/upgrades/merge/), there will be two parts of client software (execution clients and consensus clients), each with its own distinct networking stack. As well as communicating with other Ethereum nodes, the execution and consensus clients have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication. +Ethereum is a peer-to-peer network with thousands of nodes that must be able to communicate with one another using standardized protocols. The "networking layer" is the stack of protocols that allow those nodes to find each other and exchange information. This includes "gossiping" information (one-to-many communication) over the network as well as swapping requests and responses between specific nodes (one-to-one communication). Each node must adhere to specific networking rules to ensure they are sending and receiving the correct information. + +After [The Merge](/upgrades/merge/), there will be two parts of client software (execution clients and consensus clients), each with its own distinct networking stack. As well as communicating with other Ethereum nodes, the execution and consensus clients have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication. ## Prerequisites {#prerequisites} From 96de76b637dcc5218bcd76e467dbd740584755ef Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 10 May 2022 12:33:29 +0100 Subject: [PATCH 26/31] Apply suggestions from code review Co-authored-by: Sam Richards Co-authored-by: Joshua <62268199+minimalsm@users.noreply.github.com> Co-authored-by: Paul Wackerow <54227730+wackerow@users.noreply.github.com> --- .../developers/docs/networking-layer/index.md | 44 +++++++++---------- .../network-addresses/index.md | 2 +- 2 files changed, 23 insertions(+), 23 deletions(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index cf2da81fe86..e474ff6bd55 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -28,7 +28,7 @@ Both stacks work in parallel. The discovery stack feeds new network participants Discovery is the process of finding other nodes in network. This is bootstrapped using a small set of bootnodes (nodes whose addresses are [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) into the client so they can be found immediately and connect the client to peers). These bootnodes only exist to introduce a new node to a set of peers - this is their sole purpose, they do not participate in normal client tasks like syncing the chain, and they are only used the very first time a client is spun up. -The protocol used for the node-bootnode interactions is a modified form of [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) which uses a distributed hash table to share lists of nodes. Each node has a version of this table containing the information required to connect to its closest peers. This 'closeness' is not geographical - distance is defined by the similarity of the node's ID. Each node's table is regularly refreshed as a security feature. For example, in the [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), discovery protocol nodes are also able to send 'ads' that display the subprotocols that the client supports, allowing peers to negotiate about the protocols they can both use to communicate over. +The protocol used for the node-bootnode interactions is a modified form of [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) which uses a [distributed hash table](https://en.wikipedia.org/wiki/Distributed_hash_table) to share lists of nodes. Each node has a version of this table containing the information required to connect to its closest peers. This 'closeness' is not geographical - distance is defined by the similarity of the node's ID. Each node's table is regularly refreshed as a security feature. For example, in the [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), discovery protocol nodes are also able to send 'ads' that display the subprotocols that the client supports, allowing peers to negotiate about the protocols they can both use to communicate over. Discovery starts wih a game of PING-PONG. A successful PING-PONG "bonds" the new node to a bootnode. The initial message that alerts a bootnode to the existence of a new node entering the network is a `PING`. This `PING` includes hashed information about the new node, the bootnode and an expiry time-stamp. The bootnode receives the PING and returns a `PONG` containing the `PING` hash. If the `PING` and `PONG` hashes match then the connection between the new node and bootnode is verified and they are said to have "bonded". @@ -86,11 +86,11 @@ The [witness protocol](https://github.com/ethereum/devp2p/blob/master/caps/wit.m #### Whisper {#whisper} -This was a protocol that aimed to deliver secure messaging between peers without writing any information to the blockchain. It was part of the DevP2p wire protocol but is now deprecated. Other [related projects](https://wakunetwork.com/) exist with similar aims. +Whisper was a protocol that aimed to deliver secure messaging between peers without writing any information to the blockchain. It was part of the DevP2P wire protocol but is now deprecated. Other [related projects](https://wakunetwork.com/) exist with similar aims. -## Execution layer networking after the merge {#execution-after-merge} +## Execution layer networking after The Merge {#execution-after-merge} -After the merge, an Ethereum node will run an execution client and a consensus client. The execution clients will operate similary to today, but with the proof-of-work consensus and block gossip functionality removed. The EVM, validator deposit contract and selecting/executing transactions from the mempool will still be the domain of the execution client. This means execution clients still need to participate in transaction gossip so that they can manage the transaction mempool. This requires encrypted communication between authenticated peers meaning the networking layer for consensus clients will still be a critical component, includng both the discovery protocol and DevP2P layer. Encoding will continue to be predominantly RLP on the execution layer. +After the Merge, an Ethereum node will run an execution client and a consensus client. The execution clients will operate similarly to today, but with the proof-of-work consensus and block gossip functionality removed. The EVM, validator deposit contract and selecting/executing transactions from the mempool will still be the domain of the execution client. This means execution clients still need to participate in transaction gossip so that they can manage the transaction mempool. This requires encrypted communication between authenticated peers meaning the networking layer for consensus clients will still be a critical component, including both the discovery protocol and DevP2P layer. Encoding will continue to be predominantly RLP on the execution layer. ## The consensus layer {#consensus-layer} @@ -98,11 +98,11 @@ The consensus clients participate in a separate peer-to-peer network with a diff ### Discovery {#consensus-discovery} -Similarly to the execution clients, consensus clients use [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) over UDP for finding peers. The consensus layer implementation of discv5 differs from that of the execution clients only in that it includes an adaptor connecting discv5 into a [libP2P](https://libp2p.io/) stack, deprecating devP2P. The execution layer's RLPx sessions are deprecated in favour of libP2P's noise secure channel handshake. +Similarly to the execution clients, consensus clients use [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) over UDP for finding peers. The consensus layer implementation of discv5 differs from that of the execution clients only in that it includes an adaptor connecting discv5 into a [libP2P](https://libp2p.io/) stack, deprecating DevP2P. The execution layer's RLPx sessions are deprecated in favour of libP2P's noise secure channel handshake. ### ENRs {#consensus-enr} -The ENR for consensus nodes includes the node's public key, IP address, UDP and TCP ports and two consensus-specific fields: the attestation subnet bitfield and eth2 key. The former makes it easier for nodes to find peers participating in specific attestation gossip sub-networks. The eth2 key contans information about which Ethereum fork version the node is using, ensuring peers are connecting to the right Ethereum. +The ENR for consensus nodes includes the node's public key, IP address, UDP and TCP ports and two consensus-specific fields: the attestation subnet bitfield and `eth2` key. The former makes it easier for nodes to find peers participating in specific attestation gossip sub-networks. The `eth2` key contains information about which Ethereum fork version the node is using, ensuring peers are connecting to the right Ethereum. ### libP2P {#libp2p} @@ -112,9 +112,9 @@ The libP2P stack supports all communications after discovery. Clients can dial a The gossip domain includes all information that has to spread rapidly throughout the network. This includes beacon blocks, proofs, attestations, exits and slashings. This is transmitted using libP2P gossipsub v1 and relies on various metadata being stored locally at each node, including maximum size of gossip payloads to receive and transmit. Detailed information about the gossip domain is available [here](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). -### Req/Resp {#req-resp} +### Request-response {#request-response} -The request/response domain contains protocols for clients requesting specific information from their peers. Examples include requesting specific Beacon blocks matching certain root hashes or within a range of slots. The responses are always returned as snappy-compressed SSZ encoded bytes. +The request-response domain contains protocols for clients requesting specific information from their peers. Examples include requesting specific Beacon blocks matching certain root hashes or within a range of slots. The responses are always returned as snappy-compressed SSZ encoded bytes. ## Why does the consensus client prefer SSZ to RLP? {#ssz-vs-rlp} @@ -122,30 +122,30 @@ SSZ stands for simple serialization. It uses fixed offsets that make it easy to ## Connecting the execution and consensus clients {#connecting-clients} -After the merge, both consensus and execution clients will run in parallel. They need to be connected together so that the consensus client can provide instructions to the execution client and the execution client can pass bundles of transactions to the consensus client to include in Beacon Blocks. This communication between the two clients can be achieved using a local RPC connection. Since both clients sit behind a single network identity, they share a ENR (Ethereum node record) which contains a separate key for each client (eth1 key and eth2 key). +After the Merge, both consensus and execution clients will run in parallel. They need to be connected together so that the consensus client can provide instructions to the execution client and the execution client can pass bundles of transactions to the consensus client to include in Beacon blocks. This communication between the two clients can be achieved using a local RPC connection. Since both clients sit behind a single network identity, they share a ENR (Ethereum node record) which contains a separate key for each client (eth1 key and eth2 key). A summary of the control flow is shown beloiw, with the relevant networking stack in brackets. ##### When consensus client is not block producer: -- consensus client receives a block via the block gossip protocol (consensus p2p) -- consensus client prevalidates the block, i.e. ensures it arrived from a valid sender with correct metadata +- Consensus client receives a block via the block gossip protocol (consensus p2p) +- Consensus client pre-validates the block, i.e. ensures it arrived from a valid sender with correct metadata - The transactions in the block are sent to the execution layer as an execution payload (local RPC connection) - The execution layer executes the transactions and validates the state in the block header (i.e. checks hashes match) -- execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) -- consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) +- Execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) +- Consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) ##### When consensus client is block producer -- consensus client receives notice that it is the next block producer (consensus p2p) -- consensus layer calls `create block` method in execution client (local RPC) -- execution layer accesses the transaction mempool which has been populated by the transaction gossip protocol (execution p2p) -- execution client bundles transactions into a block, executes the transactions and generates a block hash -- consensus client grabs the transactions and block hash from the consensus client and adds them to the beacon block (local RPC) -- consensus client broadcasts the block over the block gossip protocol (consensus p2p) -- other clients receive the proposed block via the block gossip protocol and validate as described above (consensus p2p) +- Consensus client receives notice that it is the next block producer (consensus p2p) +- Consensus layer calls `create block` method in execution client (local RPC) +- Execution layer accesses the transaction mempool which has been populated by the transaction gossip protocol (execution p2p) +- Execution client bundles transactions into a block, executes the transactions and generates a block hash +- Consensus client grabs the transactions and block hash from the consensus client and adds them to the beacon block (local RPC) +- Consensus client broadcasts the block over the block gossip protocol (consensus p2p) +- Other clients receive the proposed block via the block gossip protocol and validate as described above (consensus p2p) -Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalised. +Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalized. ![](cons_client_net_layer.png) ![](exe_client_net_layer.png) @@ -154,7 +154,7 @@ Network layer schematic for post-merge consensus and execution clients, from [et ## Further Reading {#further-reading} -[DevP2p](https://github.com/ethereum/devp2p) +[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [Consensus layer network specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [kademlia to discv5](https://vac.dev/kademlia-to-discv5) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index d12b0a4ab31..ba662aa0855 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -16,7 +16,7 @@ Some understanding of Ethereum's [networking layer](/src/content/developers/docs The original Ethereum node address format was the 'multiaddr' (short for 'multi-addresses'). Multiaddr is a universal format designed for peer-to-peer networks. Addresses are represented as key-value pairs with keys and values separated with a forward slash. For example, the multiaddr for a node with IPv4 address `192.168.22.27` listening to TCP port `33000` looks like: -`/ip6/192.168.22.27/tcp/33000` +`/ip4/192.168.22.27/tcp/33000` For an Ethereum node, the multiaddr contains the node-ID (a hash of their public key): From 6ea6f53510c256402770a78ae6d9531ff3b0f6af Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 10 May 2022 13:12:25 +0100 Subject: [PATCH 27/31] fix ip addr --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index ba662aa0855..2232e7f2db7 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -20,7 +20,7 @@ The original Ethereum node address format was the 'multiaddr' (short for 'multi- For an Ethereum node, the multiaddr contains the node-ID (a hash of their public key): -`/ip6/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` +`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` ## Enode {#enode} From 25445b0e516019ca94d61a42454c1a1e374cb251 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 10 May 2022 13:15:20 +0100 Subject: [PATCH 28/31] mention engine api --- src/content/developers/docs/networking-layer/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index e474ff6bd55..3050ec2a94e 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -122,7 +122,7 @@ SSZ stands for simple serialization. It uses fixed offsets that make it easy to ## Connecting the execution and consensus clients {#connecting-clients} -After the Merge, both consensus and execution clients will run in parallel. They need to be connected together so that the consensus client can provide instructions to the execution client and the execution client can pass bundles of transactions to the consensus client to include in Beacon blocks. This communication between the two clients can be achieved using a local RPC connection. Since both clients sit behind a single network identity, they share a ENR (Ethereum node record) which contains a separate key for each client (eth1 key and eth2 key). +After the Merge, both consensus and execution clients will run in parallel. They need to be connected together so that the consensus client can provide instructions to the execution client and the execution client can pass bundles of transactions to the consensus client to include in Beacon blocks. This communication between the two clients can be achieved using a local RPC connection. An API known as the ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md) defines the instructions sent between the two clients. Since both clients sit behind a single network identity, they share a ENR (Ethereum node record) which contains a separate key for each client (eth1 key and eth2 key). A summary of the control flow is shown beloiw, with the relevant networking stack in brackets. From 8ed6495c259e0590264dd42e83d59e090cb66260 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Tue, 10 May 2022 13:49:34 +0100 Subject: [PATCH 29/31] Update src/content/developers/docs/networking-layer/index.md Co-authored-by: Paul Wackerow <54227730+wackerow@users.noreply.github.com> --- src/content/developers/docs/networking-layer/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/index.md b/src/content/developers/docs/networking-layer/index.md index 3050ec2a94e..3816d93136c 100644 --- a/src/content/developers/docs/networking-layer/index.md +++ b/src/content/developers/docs/networking-layer/index.md @@ -68,7 +68,7 @@ Along with the hello messages, the wire protocol can also send a "disconnect" me ### Sub-protocols {#sub-protocols} -#### Eth (wire protocol) {#wire-protocol} +#### Wire protocol {#wire-protocol} Once peers are connected and an RLPx session has been started, the wire protocol defines how peers communicate. There are three main tasks defined by the wire protocol: chain synchronization, block propagation and transaction exchange. Chain synchronization is the process of validating blocks near head of the chain, checking their proof-of-work data and re-executing their transactions to ensure their root hashes are correct, then cascading back in history via those blocks' parents, grandparents etc until the whole chain has been downloaed and validated. State sync is a faster alternative that only validates block headers. Block propagation is the process of sending and receiving newly mined blocks. Transaction exchnage refers to exchangign pending transactions between nodes so that miners can select some of them for inclusion in the next block. Detailed information about these tasks are available [here](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Clients that support these sub-protocols exose them via the [json-rpc](/developers/docs/apis/json-rpc). From cbc1e9e7b1ba5a4bc96ca52331082d1c6f57f1e0 Mon Sep 17 00:00:00 2001 From: Joe Date: Tue, 10 May 2022 13:49:56 +0100 Subject: [PATCH 30/31] update page link --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index 2232e7f2db7..d968dec8c63 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -10,7 +10,7 @@ Ethereum nodes have to identify themselves with some basic information to connec ## Prerequisites {#prerequisites} -Some understanding of Ethereum's [networking layer](/src/content/developers/docs/networking-layer/) is required to understand this page. +Some understanding of Ethereum's [networking layer](/developers/docs/networking-layer/) is required to understand this page. ## Multiaddr {#multiaddr} From ac610be871db9dd129bcdecc8e130813841d2210 Mon Sep 17 00:00:00 2001 From: Joseph Cook <33655003+jmcook1186@users.noreply.github.com> Date: Mon, 16 May 2022 10:34:17 +0100 Subject: [PATCH 31/31] fix ip address typo --- .../developers/docs/networking-layer/network-addresses/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/developers/docs/networking-layer/network-addresses/index.md b/src/content/developers/docs/networking-layer/network-addresses/index.md index d968dec8c63..e1feef8f162 100644 --- a/src/content/developers/docs/networking-layer/network-addresses/index.md +++ b/src/content/developers/docs/networking-layer/network-addresses/index.md @@ -26,7 +26,7 @@ For an Ethereum node, the multiaddr contains the node-ID (a hash of their public An enode is a way to identify an Ethereum node using a URL address format. The hexadecimal node-ID is encoded in the username portion of the URL separated from the host using an @ sign. The hostname can only be given as an IP address; DNS names are not allowed. The port in the hostname section is the TCP listening port. If the TCP and UDP (discovery) ports differ, the UDP port is specified as a query parameter "discport" -In the following example, the node URL describes a node with IP address `10.3.58`, TCP port `30303` and UDP discovery port `30301`. +In the following example, the node URL describes a node with IP address `10.3.58.6`, TCP port `30303` and UDP discovery port `30301`. `enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301`