From 70acbafc392db4a0ee314bfc3ab2b9b235b58966 Mon Sep 17 00:00:00 2001 From: <> Date: Sun, 4 Jan 2026 17:05:39 +0000 Subject: [PATCH] Update documentation --- ...2eaefa509b1537dbc62430b0dc25b8a535d24983.png | Bin 0 -> 73200 bytes ...5400673e98dcfe9bf2b73ede0a89304cc1ea070b.png | Bin 73443 -> 0 bytes build.json | 8 ++++---- rlog/wakuv2-relay-anon/index.html | 2 +- search-index.json | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) create mode 100644 _og/2eaefa509b1537dbc62430b0dc25b8a535d24983.png delete mode 100644 _og/5400673e98dcfe9bf2b73ede0a89304cc1ea070b.png diff --git a/_og/2eaefa509b1537dbc62430b0dc25b8a535d24983.png b/_og/2eaefa509b1537dbc62430b0dc25b8a535d24983.png new file mode 100644 index 0000000000000000000000000000000000000000..550c06d65c87ccd2ef4428e02e8a2a5ce6c6b39e GIT binary patch literal 73200 zcmZ_02RPMz_&<(g@9dFHGBZME2!)IYN7j**y*F_}*<_WiLUIm{y*UaQ8QD8!#W9Ky zQvbJ}-}n3A`TnoVbJf#z`F!s8eZTJ4J>K{IiPF`+Nk+^>jD>|orhZFB4+{$yg@uLV zLx>OlMMp8v6#PNtcFWik3yXyMoS3Me=hd44iT3TqCl$h}OyW;2X)}kjz zC7iDPS!v9=?=l|e?P?JGx_B-i=aYEjQ1H>rR*QlBZohAfSSN#K5jH6r>(q~;ENMz? zd2;8(M(4zA=LC<{dVflV>28RtXlFcwRiMYO`nZPurlI^xF^;jbVy}`T7_FpI;v`gB z@hdws+^w|A6l%kno-aBmy1zO9WJi1zx<13Ge1{h)wvTcJwvkS;8+{zD!JQM%LW`** zmYDET^pu>{`nOmDoF`CmJ7oIRG19L)nniFW7&bON4nrvRzdwVpyiW{`{S1x0QPe{I zv}sUIKS>5F0?(1pwx%T}qp&vv6GFoQI09XAIK5@sNPDZkJcV8$*-uBsJO7c)3f~$r zXIpEdYhoI~Ggg6VzvpGbyfYXlG1ob!)V+5n*q_G?nrR!mp?d#-r+jh1(n?D`*G`#? z6o-Vcj`FPjn089(5He*|1qNJCtG`sV6f-04j($uj(5~HZ?h^1HAkja>ag3Q(y9P&Z z>s!Z((rX@NUBZXs;bswvU_t)Be^l7Wdqk<;1?b->8d!KegydYpx@kRe=HAlKa2Ts4z0h$?DENhM1$RF z=hP-{(xI&TQ7q zmYv*Vi3%8?)_zCD@8_WuTK-D==ekeW$7#@psStQ3CFO5#m8yAUkLzn$2S z{r74v*m7}^`i?8CM4gzK7v~fhu}D?y6dRH+nG)!x$(G$C^ZTSLF+ckR*UYlgrDTH` zxxsZ|3G|?Q7hmP&hdSYc)U0lVo77lR z;L9&5H)o+%2Gy?n$AY)lNDyk%gzuk+rDoq|a6J4mfUQh+`$!@WI)a4{JM|OY73yS` znQ&QWdm_$2FXQRxO3rhJg5R3K4_(+u#okN4b@IOdJzRMgBO-doL9y+eN@ybBdZWqs zO2%?x=*uq4@KnHNu#RW#?CiFN@RBQ&+9l zv2X+esbY9(iY;=Z>|f*4L^GWQ?HnUvd$%qSZRgrn@vsY0Xp=9tfJS93l=S|VF8iU( zABWM4g3cT_Way3G9gg$=U&yCPhAVcGHadIy2M)o2xg+Hw%CqLv-p=nzdSCN(dNclM zBWyI?hTPDHXDT)s%5#jN1DLJBr-?Wxi#a1L8 z-quc8aqR^cH%|b4vBzHKVRx*w5`OQ-=t9EKI5@(%r)_><$DVj4xwP?CKGAluw^Z7Q z!^iHzYmMcPXD~j8BR6wbEFxB5yW#`_Y*YxNKQd}X@JW40w9;86vnPEpbub65POC6D1U6pI13eR9)f_9;pGo zM7F8Q!io$Q7ncd^QAzY=PJy2}^~FNb*+{E;>-D!O#Ff9($w)jNw5OlaK zM2qV&6BhP4f@xu(Y^$izv{c^nvcd}~74O_rO@y|McMX$0YxpJT^W)(9pW+4*#~h{2 zgCywiiBt_7dJy9C2Xo!lcwEi(;tN8FJ-3Fz>OH5I<*tGJK{-MjB{4|_CG{A1)6O)~ z+Ic~Lk*VlPs4nDR?ght-gu~6pc~r&?#I}VQzO}q_CUP2!qjh45#q3Ndyu4EQk`NgO zBtylCgivWJ3}cs$|LT`K(T(z1g39hika?LG40+Qz_025i2r{HWM|DEheK4?ZJ2l$Y zny~IJmf$W%{J%yHh0E*IPg4fmXQdK2c0q2qppTG8q+h6@ zvWJ!8=w=yDLgX(^!GqY<_AkCqUqDC*e`@lb;kl~rP$$bwA5PVVM~To?Vx&!Nw%g4Q z+Zq+up3B2|JW*pYGtWh9@`di*+NN?O8+UkUk$Ket>%lp8+J1|UoNl?q8R3HbA^S1u z`Hh<3TNbyx54n|b4V7@2s5FnKT%#}S;!&Op6QW{+cCkXT2TD?gdzH@IjW~z|rOiVR zqNt87`sB?2!~C}%NRFiyJ3CKtKK2^>SnVyBiQ_mNTkcp@K&*8C`_brf5&jwp`#I^T z?t_pmyQLC|`!rSlX^lu~GcRTI--v&i1=^APU^|_{U2A2(;s1#C4-()>N0sjxWIyL5 z@#2s~rDhA--Gw>3<2X{m4NRjthEELp6;QzMA>vap6br&4BJv>C%z~$!()hRCn-nuR zPr4e6RtmVqLnG!IN*wGE%dk^fMJT+V;j2Wawyb|g=sqbS(wrA%Taj*j5^2RE@-4!Q zx#?P8pG5tiBm!sb=k*>PDe99f>hsh^u&nacN%C>XSv>rK0~IYapmLuG0{PYd#WyYL z6@IA7S%%4rB>ll?WtVl?65W_x}Rwaa;F_ie6qg&UuDuTGDvp1 zJau7PzJI`r!mkuUNk*bGEJi)DzOT;tw0{!NO$pD&3{U*SxN=7`-n2++{H8!o z)EGNzWQin7=e`z4`A>NpN~j{*0&00G;KB05@ijIFSgqFUM15pE%bU9QERVH|U1U&_ z8vC?5oGOnDG?D67S`@8iKZ9*1lnMXyN?CmTxN;1lhGrwFKWih2 z{(sdu5b9;6#ccH~w!ASB8i3E4VyQ@7dkVj{=V?#2o~&IkVPv7<3Elq z&zvwU;ze~iCXWwnH{x?vFfHVgrp~k#-t-EARi1lfp3x}M<@Q6?i zuS9vOm`?_e$pLX)DLEZn%qg@6?y1Fkh?7ewt`KB+OylEBv5`suaGmW;^Tu4s+ zkK@4KiY6LFjk?BWmr)5uA{Q4^y&9eS;OKi{Xl0lL)1m@e#COB7q1$kTUh&MS6fI9+ z*?*S^si#KJl+dV+%yt=U^m(nvnoJLuXs46IHLR{nx<1a}7_eJr({5ezANR`>Aw~L{ zX=cWihcTu>J4-@>N7IxW%Bd)!$(=5Ib|x^gVR!_(_~AB;O^0oy#V2!JEf_oeOlV%r zfGg_u$?{$3irSD~?ac7lj>g{lPJ+b4rQ7DE_~I}H74Py<+Q3wIKOCW-HwXv_SpWI6 z&dl7rM%H(;s=2v&&5`poB~vZwZi+4dX;Emng zlSQe0Mf3YC@`X9k-)&XP3{nZko?G6lZEcp{tXo)bIodS2U^0c_IP=&JMfO*PCQfAt zCtC4N?XiP7!GZzrlsVOivM?|d<(qu>LSqw5 zJZt$;u!nj_UdhG9wYC*^I_`DRL8zU{r7hem^T+C){f$$hNtUY@J+?Ak1Zyb8APCqO z4Vlfys|`afilt?MInX`(imT@2#t1?=8HN9{g`u5E*1h&VzRb+D5fiM) zPj;H=>$tCJ`2@#NIV8@XujF;J;!M3T|92qRdjJ0H0j{LztOfYqo(B# z>wevPXB^G#nH7cc{tq9DTCXUdA~f`Md=2dxr}#nt(PCyt)LOL`{;+GT*+AOcx5P+} z$8{^RTu$^OEu9%(fF+~sJUlAYV0h^n84l9Cjy5(nspzDOf$QZyZf?5A%@0iDrhREV`wy$GOS-)NfEo3sa~6!=z_dYgp?pe2Kkts2;SfjO%DXmiHeGPjH4+g zC1rPXbj19y)ypvgFKzKoLcmCI+xHVh?l-N-3xs{z3K(x3Dp+c>)A`rs6sNWw6!6_? z`-OQQO4d*60aJH+CwCvg(19S*nOdlDpyVjkTFC6##KwMnwa|&=yGJ%cpEm`kwcePj zCaa~1#zOF-xQ{k!bA#8d*c=Ds_f3xu$6H%2Rm{5erU|V{oC%IeR_uxD;sz{g?wUy2 zXU?4yZ)C2^YOZ>-*tEfX@tdT6&(tpEK^zmwk-xeSMD3}2yTdfH00MHu!^1*&hKVm; zyvW#MV`g@|jMA3-t`hkBU}ZejNJ+TiD`(@M-$#gX_-Pp5iih7BH>eW8_BSYFb_^zO zCPn%py{2IEXr0^BII z$}6bD3((2_%VtJX<{bEm4x zQTborvbbm}PvcLob|&=~Os=*5u}#@3=O>D6FQ$TWP0~S`?P51Z=|u8(I5v*G z%r$=rwdzu3wrGZ1Qb`!&r1b1FdU-04vAZD zNhv6Nxl!C=M;higa)c)|VCwyHJ0A*hFz?uYqmGB3wO9{aTOi$SIHRxGUPL{ARK7GX z--KS>EZI#dMml4?Y4veqx~}?cy#6nVrX?G2JDiqz*pXgIVQf#pwX>S1Dqi(AW-t$Npd4oc} zN(j#5zl*S#)rAFrCb6i~g3Y?UBiqyVZAcCXKBL30q+RnrR0kFfs@s#CJhN|KddGmT)q;ceHW!t#icCIQC;tx)k7uaqeQ9*> zZ!mP#pzl3FZyT9vF`kt9u7At?F4uB3HMIshXy8_}@AS5Y$96aGILq?yc;6xZt6m|OE*FSE)@{W1x*QwNXh5??$D^wInrqFZ2lUFyNrpRxKQJ}w_M0!OKL5aE z;t>*%-b8{}TXetG*py4O|8T`6_yJb7&84zC7K-r6CgZyM~x~|2O;LCOjq_MZ+0e!B5XXFcJcgV|2VAlXYZxx zYexy9v}IQF4RA2Uh*F2kWskbn1vfIzSaFw;!QJe-JGt|x7b2O(iw|wb8d1?S3W#um zhY3rjFtUR-_qDKT#$}iP_vp136u}Ry{b?7QcKQ)r2&tCuaeJN2u1ucDoXzHuyteKb4wNT_t&&k=m2V)8O^__(T zIjnQNd1)Qt#(MnqCSv?dW^l{yfh2I=qP(nVv;%&zr`yNb|^L#bS2D#TNrL zS3hCqBhYoNboS@*f5$wRcUBx&LQ_VJ|H)%^Vs?7D@V76a9&v0$3Ix~u1&x4!!^QPvw0y*>DNa3?}Lk zsG(d7=?rIDRD;D0d3PK*Me9L!@!C(qY$@&-b?(ph(#27pXQo3>o06J-c3d$mV>^}I zsM^6imH&}P2*^VTtyt!>(qhZyU8&;J`zw#Ft*uO&(R8hAEpN7$-uvw}WMzMa#m~3& zGIUTQQ}>8~<5Q@-ygk-dP1N743|kH94`;GAhvD6rvN;aQ89~z&gXAbuerIO~m@JH3 zrU{dD`k8RCvrJz z6aZly-aRJU3#Zop3N<(LnY1zM7U)J;96RhXQT>~v=&GEQ9Wi{}0=Q|vSG0u@;!$I0ek;PQ`@Gz|^#+ zlfx~8!>PeU^RstScSakS7D*oe{{1^1Z%jXDI|cl4^ZMb((xp-Q)}N}f5)$X0Q{(Lx z+_Oy#FZeS_?J(brPVz4K?D@qs0=x1x{sDg{8m)M9+ri$xyJeB*%IdAZEMV3v5Y-g# zb4Jw}O&OA%!d$44>lDgldUot2IF4_j!w_auHW*qou}m3hTv^Bk-_0YCFXHm|?w4Mf zz?3!$)4{zr>sN}$6aHmPIA=HFbIOYO$A2VBWQ5b+67>JVp35vDGQ#eQdU2x2<-Vc2w%4l5f=ilL3p4N2L&ds+_cv$PyiYxZePG*Rh@mmR%9|2i zFo696Kb;B+Z)aNcT$uUC^dop<;yK@AZ*8yr7}lvZvIzEG-{$Xnudr9%(@^E8e#&)O z85yp2y6DfyM52f6LQeoG*nQQ6NZMEHqhnqR)+i$sq^_||!QUWkKNatThaAoAE6B>r zmze9E!q9dn`Vz$=tvKq3H2Vm% z4%Cl&prm0?E8L)`TPf$e|Cf)(N=(Mn&{K|O%~MH6b~*lq$6x4MpBL9PEN3{bzj(sx zaCCS$f;nxvw58E1Q6ENl!Eb*`hj|u=F&(thWrNgfd?j*%#xb$=(ZIk!Ee~qbr?#=0 z2elX#YVT_vyvW7&=EKfVDbN2Z9t&b@3yTx=$+R;eSVa%5JOUsfK`P!S+cx%4$mAS7 zIpfWmnQAVSb^VJr9s{1XukYCE5cm!6b>prpz(E!2SkA z6*)?WL`OJ}Bb%)N$4Wh)#{YzrX(}iITacT+zxR~=>q$Ta+FG#YHG{HZ(t`0)-qUAH zHsS(tg|)wVXdTU8FO+)2TkPu{DX2x51l7LrE`#g@#uY!G`PR_5Qh?sF5Cx9Ftz5Ph z*Mh=eX|1UsDic6q0=Gj#LV(~G68u#3;k%%`GS@Qi9#Au1tyKA6>{%zk&8^mL6KcsF zhy)LeO|nNw?3{05IoNbXy*DEpQ;(e$eX#x()ITpS8hXc~VfHr1tCmm|F?sn}Z-TMc*N^Rii%EZPr#|~8x|27BQ{Ny& zj^Q|Vj5-X44d{sRdEonx>cOIBOr8(X8|+s2cTPm53ol`@K(k5Gs$?gaY_6_QIeq|V zdVA8Vu=et*DnJK(3uBwnHE&+GxuPF!@F(g=f@Mnwn;4^Z; z3mn6&K`w1$Z7i%omyEl|h=Pr2`yWw5Z_N7CvZETF3Ggg=HY{4-lYY;*w=iXYQkxg` zwaLtfLYRn=p8e7U{!48ur`6U72w9xFEQk`yd;`?E32h(5YRGHe_t#vwjyG1wXcc$? zddQ*-Vf{77@Iz6I$9REHYD=@RztHU@yG_r`bmT{EKHP7VqJfqLZ#a(Pj(O%DneI-V z$}JP|@No{rmTGcsEHQbY9&isEI+FYOi`&L(opYO?N;byvS7sOwj^isQwyagyZ-Z)@ zJP0DNEy;(4*+vfN>}{Bflzv^&754Jjgaj#C=+S1Q>kYVf8y6>AW=@dt7pg8G5R%s|{U0uP&ZNIfT2$#D7u6}~GmmZ_LO}|J(@Dd2jkm4|tb}4zM?g&Op<`#m za!|KN_XOSmxSwjxSXVO~gwwXRZ-2J;f5&>OF#oNgG6J1Kpex|aHB;yQO8#Imxfz3& z`I;9tf>ApS;Tm#byStC_g-`*rGYD24g;wd>)Ti}EA15!&(O){AQn-xc$N*n5x+FKL zacxyeD5)naFvJTsnc}yN^%Ykfvvj$g+ZU+npaa??JPHEZ8?1k#;ycS7TV zzI8X`Idy+~y9%)RpQBH$pD!W@9`03|sUyalH@){lA>@i0{%EZKCA-8c{u1eJugN)4 zF0-9=ZKIDi5kX`gTMnVJI0Dk;6>5JPf=vqL61CJ-8)p6ZUueO(C=|7?1qTO{;f-x? zdw|3J-fwN?a`&F~9-kzTo5x<;$~=`-$%!TImV~KpqBFdOn84W&MVM7aZ1H83OCJ&mC|{?1|NgxJ2Q&*iay)wYBycbz z`a0Dobpj_5GK@k2dK`Q@#^1!p_o(njMdCQBS!-%5Naa>sE4oggi97b#g`ke0A_8>O zNCX#ZCR06Gb2J`Me|ZlH)sOa4>l+vtPlevR=&mv=jPz|insx3)fJ|U4J}&M}>zPEW zOVPZBoK6cCH|U?ra6?o65Jyul{?#jdxWPqu>OOo^4#?dVPw=hqIUEiLaK2YB{-$f+UE%)nM5^Q}%nHRT2b(V$rL3y%5(^AYXKUIJA7xnME)f zowP5xVw<+K>bWB{-T7n1f{Y#YBSL))H_iRg>#QAAs)&n=9F~!#z~}XKr#SSKU2gDN z|J#5S*-w*c=my}xCBNrR%WSeg>ZC2}w=ImycZ`3r(d}6k90w+O7~cOvDAtHT5KtV% zV$PINzxy%o?0mq+z04WV`{iFkwE6S;wFrOh{1hY+HGo zyG+eSR{}@ClhG?TvxZwx+2_Yb9LxG8;0Prr;FCt6N)T{$ii!0=Jwkwv(PA zsi0*+O9BE(#ZS?PAUS^V`*bg*OMibfg}{Tod(i-Nl@r?#^E_*&AB@D(9WTv#0`f7Xs-5Y3UjLSPl6uv=eYHcoesG4nC2ey2Z@lcz-Q3W z_1LYZ{@@24k&(@y^qz%}$3;ugTs9NHQ) z?YCc!m7vxhvmc+bmRuwGR>ACe|Na-rsOrFdm%tw%Z+^N|F5I{-7C5XWRYC>j&GCDA z*l?O}WFW^LTrRP*W>^=Jc;OOX=Je;Ti{~aUUqs?b{c!-r+ZEMqZdB~Ftx>=KNtEe! z0{&Ifz6P)gu7gtJk#WpYQv?d%;I;BEzG=Az3>Rx7trFx7gZoZl$vPWekK@GhArrmk zxzn>fC%O_ilodvMbm9)T3*^4uld~N1SB2GoIca`n9}MOW5Gni?lAP4`_P>l z)W={0q%?HL{kjA>xYHvp6$+D1i^j&hIvjUR?gMFy=PCx%=xjLl`)JEzQo%3xXy#_H z+35oqhdW*F8f%jyLW=I2M{lPeTs$BhqJmZgy8%)oyOUH+j$G@n^N1H;P|5Zw(OQ1l zf^{l%!1Cs2jfPnXL#vX#;nkhqAMD4UuD@w}>lc9Ihy_%vw9OAxtidE@)e#QOyhn4(qM8syeEC^9$n#loIqe~5CiAEh+VG_9`eR4NuECKy#>Mu@a_$XFs5T*w(S>aTCVpVt_N z4kyq(6>YE}5mtGTVbhhus6%i8O~QY%GRgT>Hwp3~Zd%LF%h70l={Eg-cZRPnTq2*b zQ%-3d4K8>uZ_n=uk_aBm^tjBb(!?8ge^IQ!acrJ(;zIo>xOoS#b6EdtxgtBgbgR5Z z`&ivcQH4nXVi!#aFF^ZBmBLsf3%R*|QD7`q z;{M#R_%}Z}8IK!m+fYs8Fa|dEcFQD?;3{!sUl|$eUaX-Y=Rj5PsBVM&(TV5cPF|t< zLqk%pT4&TecI?>$)R4#1`MCws;Ta}S$M@pV#~b(Ty|Bjpo3ew7vEo%E@ZrqCJp+rk zioVnM1gxQ_vVJU5nn&1AIWQ!0b@DMdjx*hzFGI|Yd*WNHYc7;(>9L|BDB+|1682r? zdj0l`7nuiJH&9o0ge5F4&yAYNrW>!;9NCymo$GL0LO9|7;Qy7^sPRfBlcc33RVTgX;O1 zbwqM?z_}|-hWW~Q5wJ)saixy?}fsZ z@I7ZD416BN!#5>=)CXd*{%^7hz>qk-iMYe-SmpXPI3@u{Q=ziLYikgm8so$k?Ro?w z0&2KQ39U9E;*~4%q)K;(%)XyF`Z2#B_MPjTH+l4gdhH-zAMuOhIOZ1z-ZW`RWZ<@U zmBVpVu=nS&B;mk843~u4e|wXzbp7FVhU@1K@|qMk3?20c2Qkpcw@}$*L{@X#8#p5k zkU&%>^^yOaGK2NC_a;P3!Ev&8>g_ZE@P`IkQ-{lH-5Th3DQ0t!WDP#0#4N>yc-gdOz8 z|K7wMlX+?cAQc5iJ3M4z?((M}%P%j~`QsZwaNeHO_&6Nmi#4xG{M;a0RzA{gc5+>L z$@Wtc9Ni-@F!`rU55`W1Gp@9gg3$!2aWO_Og$&OqiI;zl-iDnUyX#_vcsj8-U8XUd z8Pi~ED6=M6z~>#Iyme60R#VWLyCPpQ{MGb@)L}4st~#NXbuS3s?|o zSl-=T?nV~YnX01e1no8B97xJ2q+pEM2$d~~C_ zyHk_6mEr?sHE?hzPf zuz1A{W!_(bf!q0hqJ}R%mT%4uCU#*%nzaYlm+gJL@g9+CZ0*c@Qo$uR#@h7>Vv;w) zJ}!=SUah6TKS}%7!E<%E$8_UssnSShBMQz^2|EEP?oLXT>qv0yh|Nscz~u><$R>XC zw1AgH$ki&>t_#qE3sCCA@%m_$%x{WUdAv(w138I@LB@6_jKzwJ%-7_153he+dy{H} zk(-pcZ00d7m&m6Aj`n^!*@(p66=ar6V9arVb*yzRz2%~>WgnfJ;-8Z9`f~4gC@j@bG1p$k)7_Y-fUtG_Eo$Tl3;B;lxvok!3 zk59VG!t82H8etbG6u5}Org!m@e9{8tW)&jQJ+IMB!>yYJxC2!LZ~5K~_=0}d>+{%Q zw1qw1MBKYGueWE7$-@P%m{@^|)3rHb#}UZI>3wFo;ONnm>el0&dNm^IygI~07IRA9 zf7=^Pf_3!aV!qFd6F))^J-cZ-p+ur<7z|7!|oCZ=_XF09_bd1ix zm(d0`#?YAAwjq%O>vk@=%8Cc1NB~l}X<*c{UQ;gX!_?J&l!esKXok1i>MxB~^vZX2#$1!!~4eeU5 z^8{f<8cAxbxo;51kjN|Q^34eY+qJ9dfcPu_npG>RIXR6hm^S=jeG+kiI!V9&$x-Jx z$B<%g6$cHj_SCc;-bXV`Z?&!5y#i>(eep>0t-X+c1iGgc%^xU+cr$rek-;cM;y40P ze;#x$Vp&IGHky|W2K;syKwFy%Lkd~HMF@;12J(8?*7AXldnJW={PpT}?E+gre4z}blI;KG-B zk%es+V|qcqAk*~xX~N;6#AKRWK|Sd z?Cz5UW4zQ*n{mGU;J9_~UrQT1xo%s1i~muD4S?L}tWo2PNMLf?UnRJvQ~XRMXV{Pi zlbTyo<*nV;^o-#IEk-@yOcGUZu$W!C5hXoAn4uwq0A$n|PcMbT7{i3GN z)hS{Do%^8cL-OP$m=DSSU0uN$aLEIJ-cy`J^DN#&?MP$mfoHMKI5|={f3l9<*qs+& z1ta&tg+bkq)v|u@yX3xvkicnCB8zPjl_nQfOl)U^%GQ0)$Ix$)*g0}_D{3Kp1phEX z$5RSp`;ICn31!&Q&3o1*5KXZS>*8gJ%0(HfoskHG{*M2UN={!(Qs&G{Uki1zLb;!E zUx>l&ssLNX=y*T144C{Km5cRvn_V}^A$is=h%Eo`Um3!&Z7nt~_+mUOyhR9sZ?GOD zru+CkC1(Hx;C9)8z;M#pX4ld-c_cwt5Oe3eHs7KzSC;Wh9ZZ8^SJog__YU1bWZs52Hx%m4rg~; z_G!D*RAtD?P;!820m7NbQ*z8vDi8F$dxUnAAu)D zAXt|BosMGdHds{PTDvV(Z+R1DV{zBo8{g0ykVkH6X?xT~bz}waeUX53dbuo)Dnx&A zup13z>;7IJ3Fc~TUx^JTZ`bgh7^SZP^;oVh-a-C_cvL{YP0fD*#tGr^^=y15>hmUV z+u`GAUdqDG1)!6ROAC-}H!i6<0JYD$Kgf|4(?e5;AQqwebkj;{Dq~RQWOAM(=TI@o z4VS>lmyMG`8d75w(~|Xk@Be}=Ix{Z2$M^z1c-F^IbVD`16|1RcAno!yp6>T30*N@f zbJ2@cgdNAOzwgmKzQp!>9*}jd{xCGZt&ex_zIC+Ju)YiCeg=z#mGoLswkGJsqLn4nCFNm!J#;5_ zr{&dW{oqX1Ewj0NtIv=9MUPqkTMZKrpZ_q6=*jBAmP|R$Wb#e_YL2z!NwJH#hTl0? zw(i!hr|2;)$D=h03;oy7#A0i064loiwu?lCg0q3<2)LUSh+&5h*)1KYyYyupS6+80$#o`Aq#=3OtGVTgw{_YoQfu zx1(@^T`h6Iwl-#_I%Bu3p3AZTKwfUT{nbKWV5P%a+qOt6UoNC{=REOdVNcphEiCG! z5j0(C>_7_=SoC}9wqcD6|>Jd;#){j>I8zQ`u^+PCx>zC~U`)!)GD zaro&!>G}=Q$Y1HcVwYoPp|4m+2J2qS7fwb*p!u~8ll&TNyNMvUhBf&rps)J~FpvC} z*3X$+$94xv0yd{6-n46FDgk-dTGJc;wR7iC9H}F~c zj3TK1kC4(ZMcj|JR_pguuMV|5rBL};MX*aGGv-rQ-JJ_=VZ@VakvjKcHGJ`L1Z2fH zw^*QUM_GH;4~KQhWey9QH~*6hQsW08WMZqpysVkg#9{t2w(2c*8oJ^!aO!9B{vUMj zO>ZV8QhLESPz{z3X2L#&aX!2xCR}bSpDti{e$~aJJ+v$104RWkgvsPuCv8U)hY%d8uOMZQB#a|RvWu5OG>!tUKMyMjPv&!7asJN(yFx#FPWR=s zx9g!2_==VJEss3Ok{9{t9!MK(bmllI_!)F!R+BJkpwAeCk2~gIDYewLSDO@=@yWDv zl5ynEtnvA-p~nYw5hnbe#v5kG$>XMj6uaA_n%yOqnbf4Cn0%0tA1?Au56$t*GI-L{ zop@Otlxb()*CGTbsWz(u4gS6wUwz)VU{PmQusFZ5{82wbXw%N2Wd$ZM-k`ez29+%K z7KH?uDEKdTG--h~6?Ak=0i#aCld(k@onb41w<*gx4C28Q!~3mA4I8*+%hlxkT05IR zDHemN7gZhe%KY8DN7r)e9)tap4xt;>jZXqh>GchH#WTmq_v#O3kCe3E^ARtUlyT2Ln0r)jl9|y3hJ{*wcI)F;`CX|erw0G? z-~l&Y%nzEk-vV>@tVw3v9yg+FX&D??&mY(Z*2U1MI~p|_*LBaM40K$)417s};=V0P zGgmi&6;kz+|S8)H9jS2k?_KUVumP`-+nEKGCi*IoBh^ z!e1`}(>>F~6D}b3VVdrhNwhcgkF^PH%2(Z!1yW+!$Y&PU>1&0M&VqY>QQ|Lm{$~~d z*N|#kH4I_<(zhSNVXz4ku+1eHPyg==_({8d6_Xj@JgAQ&PuXDgdVy z|F|srM)`m#+ok0o&ajspiNwaUQ={5iF-;MJweZd3`0vPXl8#75yU0d`Yo{tInsB(D z+PK_jnUoANKMMR>odDEwUYOGxEq|UD0OPne(k4NxEzt-P5&%h!hL{I~VLR4?5K#k{ z9n*Esq;Wsmb5;^1$$MH{nlGp!*bN&^{`D5n*lgAte+ri`nl5A}Tz{>P)#HHUF1y(# z-N4TyRm22edKL-xAasN-$y18Smm<2yg^`R_eUZLqM(1%wxg*(x$Ln`VT)5nN*2Z_C zMb8`3`b9?fP#&7=E?)QY@8b!3JZb{jU6_5Ic?DQ$6M*1;*@TF|^yc##B>$8CR-&>F z1IqJKi-|bJ<ASkiL2Xy;)@S2@r|fPbh$#BI8~Ex=ZW0QH z;L@YPXJKb;wL| zr7a+qI&4}NxS1^|1zrf+J|WPVamtWjnR|Y+v!$Uq5gX{1^P?f2S1U>avy`}Jc+STt z7iNm`^j{qo`gV8|_1QsTc*YA#H;r}QX&LC;R)MYdX3OzX4h^^DzLRHhNl*s7Jd`5! z4v+P#0!D@hl%YyL&Lsh0`!}hvo~)tltrS|opz@Vw#nV+AL#BEh{&9$ttC@`{OX+`7e^Vl z6UPX>vT=__n#|>;Wd?Y`uo*QS-3PRT{GgfVo_=n!eI=iKMEQ6a=7#V2BSRqXv>M9R zW=VU&P(jTN2B$K7xZK1{!O2uD$qS^-WY}w$8kP$R{u)*({@HuVPnTe>+Kf@ z8T}hmCg+=Hq>%oV?7Q|iVFodRtGF2+Wyw*SG(CF3t5h^)1~e-l9Dx6wT11EH)iHs!mS_`n(0B zaGrH7AmEP%p}0!3rYGhUb2lr_SqD7JQRaE@sK$Nun!48;={UVeJ%cBiP9FgnHM2Q= zEO!0eguSv@$7w;ubV2+BI(n==r31b>>_YPLWbo(Aa-09exLWg*mJQ@vZpW3Pha4 z>=-P zhC1?%viE-t`-HR$y*o?fZ81tMoQ#)jG+bIkC>XAvk!@AK+ETpvHc9(}3~FeL|2~Oj zRY12-lTt!0RexPcJP*ZK5!k>x)B0o)Vb5k{rb-g%tC;hCxRgC@IX;_qH+WJxlE#s{ z%tQ2u-+`X)Sng7Mgve)uut%;!t-f@OII;(Pq?Y7!{GUQcZz<-`!^)=F8@0jjD=s( ziDvSB)wupKZaki*{%4}{=pi5DHZ7tF3tLNFI29F|1j;W{j8P|!4vl80@Mp;qjWzm zz^$JWTp07<)Jp zEP+{-PJ#wxF(|@#rsdm7kw0sw_Wa!D7zV_%{IcczlF!i7bhh%eeBEk16I-ns9wz+_ zQ(m^M7U;T}9wrsU_Q%Im|D%yD#=ZF_(VW6h>Me@}ZwOq|PG8GEh=Jdscv4$S{qzQj zfl0mwtMmJr9I(m34vZ`uyxPJa=%roc{TFgAzLr|jcU}bpY5G5x>y})~%F|x93;0%e zYVsizo<{nku3pdHm$+lrUTmSQFW}pb6xhEY0_~=oY~aFq)@YQmc)4$HE0J%9h*|jfiLL%yWl-Iwg=`}XWV=2`kyc9NQpp`&vbW+7sBvq|MANciaS5XGvh&m3UAU;D-i#|s% zt|%THJImE_r;+NhslPeuc_w|I5PARR^VdhkYZuKH zxaq_}beJ+T+~{IVKfbCP+S-_!g~a5mbvtqW$h&+79hNl|W4+P6PRgDyaQr1ctAM!m zNBoMz;>9`VSeBIxqrlSm!X}9rj?M4mUT8>LN?N#_2W83s8dRowSF_gVKDRSaIZrcI=Zz`^#WAM`qEw2fp^`{ zxh;OJR1)Bw*?1ylAI;>(?0m9G;rh zM4Xc~nfq$TwXU}mu~>T{K=<-#hRWlBEJ%M+n7Hims`X8;v=Y22qcn*?R-OoqpAr3> zPTamhaw~>;Pt^BSwo%(7v_?y(mGrf7{H)lRMuqRLl|S;Jr}Y&obhy_RVC??#b*8`4 z4HwM3FvXmXH)wlku;)FgA3NANB8St4XvNe-h};r`^d{>hP`jxUxA>iib@hx`!jNXX z^(F`IiZO2ysiMV(x*(cR(A2S>BpRtElFtwIf`Zn^uXUO`V6!d#j=e%Cx;;^8|7r)f zEak!{wXaH_&yb(8La<0N*2LWMuRIuL9!cQnN&~t&%MI#M?Bg;C4xxWlP6LG(G4>Je zG`l!j+^de-w+G02dKy_pmU-{JSq>)T^Rp)}d4_8kY`cD3I0Sug9t%6GfXmoX2evtk z(C=afci{#;?*<6uuIoH04mZj0xYDwDl_L7gRLF?PAcp(N9$8)4J5(+BzE|dmOC^D$ zGaXp5vP)dHn~gMh`S*kpLKSGLJL0TIgWG;Xxr2#&KiDqKD~XsF%7v{2hM-)?qQsNg~Kb(6C=u5?9%yGac&+AgX$5 z2?Yz^P?Vk1Rv1F1CfnwOiZfslrgoXr_1-X)`=HkYXXx?xQ+~8>x5!-0H z2Pw6flZksg8mNL3GuH@uu>maloLPD=X87u^GjRjzZ4m~Or3c%Su^2(p5s^^zm!|n9 z6e9wx8Jz(qKR$l(A_)}X##4SjUy z)CZKlf%+-%UJfBh9|6P4Q8^?A0wE7`!RFW{J+jLT|E^kuVp}X*IIEg>@NY4EDIJh_ zfj=h}iXQqyN+==n^xOx=exlJ>(*#yqav)pr)GC74l7g1jbqLsS&S%mU0me|Zg*|xC zwK-EiOioT-To!TSwD6bWBHepRU<2VIm4hzBIWgcb#oUI}c_+aDZLVQ_>+jvNy_3OW z3+lg^Rm};hehO~O1u3B1Bj5ug|Gw_01VUvs)I@e3(%|^~Qkr$*mVAF7+LAUc*`^bNeWr;5B{l zVFkz0PYH|P-cghpZ-HO=^UpB6BiBgYSJH5b((#V;kZK61h_^#kmC1|7r0b*PZY&&3xpHMvf7G~DG`RiAZD$ZRtwx4K%5y#6)u!1Y7HI|d7 zn>{rK+o(oMpI@;ZKbYM;+522W0v&nbza_vyFfiKwHsI7Tx5iIXm=0(1>-~RkV`qZ= zrgs9Lc#sH559u|T8ya;4y8*c+fjhs!PTT)S*L%mq{cUZ-ql*#|LG+U7M2|!Xf@nbq zV{~GWsL^|iAbN`tz1P7g(QB0G1VIo)^xk`W_WaJd-*cYNbHD#GpP6sjd#!6-YhBkK zK0Z2fzO0Y({JmglctADe7UV$;I37uCsIx1Smd@AS<#De)S~pp#R3JS}h0g%8l{Evm z;0=NQ5=PiZ>U*JJ80OjnX#PVq1FY|DHh{_CqL%&}AWd7fe0wx^bA1x@X1>(5$*K$G zy_TCW-Z=aBZ(Az*VxR){;v{_EGTFIOv)H+Ad0hXU>SaTE3PK{QDO z#VuD`cJVer>PFhQeZf(|l9%)ARfM2MrG&-q?b&+{2v7WMoCWXM-uVSOc1Z$kO>TER zCJqXsf4#rR|9XF$_qe@AefxN7WYg$``1#e>T;4hV25&H`vAL%Cs6<#TIW9flpa!60 zNo+)p{-fzRAYw%ts-+p$nReZFRz?4UH`uV91P7?tIBh_dtN>jIib@LThH-%>qk?d^ z>Nm8?KB?vB98evG9a58c{%W^0T&P`$M8@cXxqg?N3G$d@^i1}cl^59K+9(|WL$2|; zdkXW@bPtk-ytf_4o}wSwA^2KyuKt$i#_t3b3ZzZ`?_W8dwri>1=jgRc@!YNxHsA&7 zYvE}EyT-lm3Mj62)WZG#CijEo-fEe|oudzwjji-RQGa|(&FzB((1C4!kDwXDL42yW znXVp#o15pE`qw!D$5iQ zzh2_?bvK)dwUF4*aW+zGu0B5+FE!9R*#H7}t93~+v1w<6_MLpPXYdA;_|rpl^hn`# znC)2bj@s3Y4Wz;$+q1oplG*frf6uAWH1l-eBctW;%OrRbPxADe3otk^XsRxozTKx+V_OB> zX0kWYwiUfAEbb$5Y4Dx*!D0`OgTeOFI9qbJq$9AT+lGL3Up!4T?v!&f~9&h7(Io)!lxAa}v_R|Oj%)yaOX05$T&1XNZ z7jog!sg|Gad+N5PY?SoQpXHYCGPorYX73yVf`K#lKVKL@#w8^m>m|H^$8T4iX}5As^$ z25j<7=IW`l*}A$qr7o=_`{hIn==HP&_@X45AbIh>q&6tDGGnf2hkSV4(qN>@sgqp$ zm+Ea&hJE<=uh@w0e`I088>ee(zPf8~-yVA77cV;#6XrbF{~$t z#i9e8Flt(5BK*^@U8Wi3l4dp0dvZdu60(R}Q8V2k!dBy&g8|SHZm-J)hMR&<1>e4X zLy#cx`y!L=n(G#hl+Zf&iDG%t(R%j*7v@yEiY+~Q;P@9!t&p$rIkMmdm}X(Z6zpZv zFce)C_1@VhAxhA9P>jg1aY2XTniG&vY&|1({abr$TBkw*FY4aPoQWF<2lHhAMly_g zIB_Lx^QLp&CpH_N3lx&}6i8HBJ$6W$# zZuJc9KJQ7C&tdj!Aog(|u(I^IM$6_9dd*)#b1<*HNvS`~~_EuozuTO^BW+ zGH)-s1~jUkN*OPST#bx{{Qus)<-E*t$k&4=lSJm3M`H)}aIrT>dmy9cmrTSb_wDWh z+k&dKiC{ZUB+hr>@}Q@KB#KSwR`GP(Fm=XDvhGyUFir)^S7FH$bc&g2_V!#%>Kk6O zNC%VI6@gXfcS5L_1jUbknQpi|P@D*J+V(m~o-6+J9jLquf#`Zh-b9^ix=qx5ZvSiN z?jBIc*UV2Sv#B2hUx@Ek9SKJMoz&dW?S>0|+%cI4;u3s$;_0Utw{Qs_tPL;7U7 zQhSq-*h9#PNaH-Qvm`PK_=Cl}`$jaYecaWX-A5$t#BKems1hh@jdl00=zQunx341{ zJ2>)=#i4L^cohTxNW%`9RmPeMkGRg1?kKz5j`0o0k3{bzVN^hCuf-SN_(pV-!!hm1 z@$2F@QH2k}QpVpXSH29u&?5b(`@F~VCG-_IWn-g*ZNa~VG<_qS?gf&#i)tZ{x+8QN zQuWZ7ZG9HMFAjIweP{n?-Fw%7-;5&3GGm3U1SHi7GPcFJo_RAv1peeDj;Jx2TW#qk zRo!dwQguy#=bDC@l4Xmq`=8DoJz~lV4=7UAL_X2snGPm$}ev%p6c`eY0 zrH!#{#MHTOdEGoe(87ZQsLe zhRGLrU_3d7W&uFlWvKB{ucUc*|0rwXOP%QMp`^FvtPWPh<_5v=r2adB)NljiBPy$) zB=|2Fn2t*F&?^qPmyg>XvYXHpX4aH%iQ_1fB|d|krKo-H`ZIa%aybvhB{DO=MbQ)j87J0w$*1_oKilLxD&id!Q22wB!y>G`&Y`!$}!`it(N*Uq>}RsXuOd# z#8)dFbzbMhS@sZU6i=YuQMgvjjM;Gm#-57fxjxaG`< z0r_kY`$jFOt?1V*Bv0ywA|77<1C@?OGO3mF_)-QKu@afp=liG}ine$(W~0nx69Z86ppTX~+!%p`KrzR`uQjAi?Yv!6wy zL+N?^g;#y9DL_*sb@Tm=#DH+m&=mCOV51}qNV`7aP27roPh7!S2CPEuO$YSj`f03i zUoXGS=uA?ux8&P-Xw?{Qw$sLLpfDea>wf57xpT`-Pmg(N zJi4Fz<}1KsP<|;$v)W6}`=+9^z@tI2p*?b%9H!CdAsB>6NO*uE_t$E9WHnJ*;{Mjp zsq`y#sF9j+4{fpPP_8OARN`3{eyYc`#`GFJS3+NW{=MGgqUo7!mzX)LCe)xX*Dr(W58dtI$94JXc$^|snHa9O5+qJy$?NW(QI}aONwu+qIE6K+>J(jz= zR`dExh8(|UxY=U>c{?$HqU(4ZdLzYn8BCHGMj^L}`}F#B!KMiWw4v^Sy->UlY&*mE zU}Dd$@Gba(aLoNCIk`Cae#66-u6u4wO2Xast<+ZKtnNlufMu(xdU#gwt$3q5ETP=m zkPp3zQ0IM3{RJTo3v;Wt0?=!~s-~Sb>wjheY-tybI;XcZV|m0%(gY~v+YWRW&4J*L z1uLz+3k}2agx^wNL$7%3O?;-e1aA2TjnF+rCFB7?tL?nan*q^+q6Z>}U~xogd!ww` zUY>i!{8M~z&$b;L%Q8EA`1DCRyNkZN<1T8LZ4(!}5Ght_-n8G*DUIQjPVjLOO4zu|9D^ju}#6* z%pd+$omhpdR*0FEs+s#@i{G3-y+J}N?iy=l4*SSWE z%BOC>+Udu4IW*?|hX$5W-DI6vpT5@KO>1zzI+}3hDO2x%=!Wzw=k z#&id{1ce4m%FLr^B1K7IvAeGv=Vj}|b-j(6sB}k`K7W7uddEU?Rhq=|^ytX^ui^=e z+KM>M>;ATojjL^f6Opr+jIy9biv5d$a~k44JJzx!iF?`V9~a6l8-S5ivX9zn3PJ}u z(|F_I*a|GF@4;v!YE5{b-+_77${1If%hjXu#A{zffBqM53VIy&n#X{CmSFpC06Zs? zTK=H-da38#!1PD#QB8K^Rd=@|-yMFIoQ!;cieG-P&a(gMXt(7@*r(MO#yy+4yG$C- zt1+D`$AR`ShC$#{lMdYNkSUnI2C&rw*Nk0mx)dl zfXHPgEryYvvDGze`~2B)zC<=kv!I{AJvEuy@hB(U>33BniyH24Z3cm9RNR&|bqt=v zPfup!Y&QJIMezy+E;*J>m%wz@=3<^;zv1EU7o)W>xc5*}CEQ^w&EtRxwE2qy|)8 zh#3f}3qE=BmXeZ^tFj7S8s5J|z%YZ)y*3^#-=xjJ+zpR*s<9fXYz^Ir-jd(y4J=TL zeW_&J12EPvCuFkA(_lD4_h_$B&6{)hHfv&uGpMtEp$Q-1@S1-~w6(oUh$wb6KRHpm zx5}JG+YFYZ)l&PQD#o4;ILn9pbOMH7ps5OSPO8a zQRR61ZLwlxQg;9$;Dfk)W46q!8FH|~cs^d^|0X|iCu(pM8kmI3mgC|VpIU_ijzHc_ z?E`o|c{z@pUYJLRhd(c^&Iy5YK_1%-+7@g)dTlp*dnu@J^buZNNF3AJ%|7pq#w0z5 zpu?h~m4I(iYW8b?78xM2_@#^|MN7$t4P973`CeJ+sYO{IQCWg<;^~ydZibgL>&;2Wf2O1~N-;3Gu9KL{4m;H+;~2}J>9lIT=cC$JI7Zb6fq2|I zl|#>B8ggV=(QJ}coiJY`%Vvq4w^dG@-eQut%Qe7V@&jaRS@fy+#pc0Iy-os>tYCO{ zi^(wpzLDM!3)NLi2Z5ex>}_?*BJhJWII8kJ>oXFimg1FJ%)QtK?rcR{$8TB77C9Wo zf>U;8(nwNe(=@3m(g)U$<56BL<4@ns$X4qs1<#{laH%Ah5m2zNkTAH`w$s%YC11)Y zxOs|Vav8-8MmhtX93@MC>r^|v9{$Eb`Lsl8`CPyTmiir7_V=W^`?llm1oI{Tj$Uli z#wE>v(6r~$>-x5U9<$QdVg?!`7+T)lrZerS4D-@00+a`lY=*Yf<}1KO)V6J0;(!UfH3*tGIXW8qUF^(Nmh))7M9Be7N*Wln0A(^QII z?GcR6w>A<}r;En@T+_5GD=Re3ssJ4Vx5J{#6EuS)tTwvtqDqR%HHT@{6-g&7`19l3 z?nKj;jh)_+Fd7$d3Dl&fGtF?1bV7Hc&s+q^)`6D`0?njxP7BaTBpFgPJyu63}lXtinr)GH6f{s0rPNbe&Rz?l$7pRu&^WK|B z(=lx#aa+IHgC-sXTc^fk?y2*ZF#t;(;4^!)Ox~kne)@uMH7%M-)*hcbMqS;=!o{U} z8PKmj_{F>J_uxUpi;IgkH&??^K28G`HJ&Hi)#+_)(|?Lcp3a#mo3LSZW`hr2ia$jl z5cNf_B4?Wxk`0zT0;WZiuhr2En3I#un$Qt;lG9Yrk-)lDs>ga^A}MVDx-GbS$kvhr zlN%km$?6mhH@*#c#(k%filfr)XDW1M!D~M*J={yi3-me08&xYyVg{;N14*zE44BGpw}v(f>1nS4NRSjj4v4D5 zqdnPngnySzDjCllq@5I>c}y1lQfX@FiA%p+OtKx7x~+Kf+AYJUO!!HO_%eS~NC_Fo z@2lm?*4U3Ll|2^2Dm+UZxoC=k7kF>^|K!jB=Lb*=;@J{OCtt@!DT=I)7&? zVlWo-w_sE84(y0mC_lxax2R<`>^CqnDRTOt$#7CX(Zp=f3cv4sDolS|7Cc5|lA!Z+ ztI-fva0RH>&DAzey^1yi4toOb5F#dojqbcmy?9n})hrbFVy;TZ%vCD%09I{Z##j-4 zTdOJGC3Kg#uY~=s!rZqS;T@sE>L!&wfoSIQ?`Y;|+pOQXQh-Mp@`XW= z*D((OtfM_NJvHC@$NUWNMwRQ%aJ_jnf2Vabz1PJsH>@&=PDhcmJELjGUz3uPYjF?{ z_1iP7UfMQJ8z6}Wc3eCooD#cND8Y4rmV!G(s#Z)vbnCX{<*wFE1JNmBD`Ts<)OvuJ zp@OBHjAIwjNkXx$mOpQeu6t6;nFnYwRHPN4NYn5r#Hsdxsjt;3U)b0EEXt;WJm@~j zEwEvxt8Ik!zIs!_j?!dLgG3rLv(vB8H1N0>xbq%HEa3N{B@oE8y>`$#E`7COY+il$ zMLZb5*V_P61c1kuuvZ2@mglh@JN^s^lTC<89t9m8lIqDle-f{Z>Un{eF73F+WOkypc4MYxnZYnmV$51(yB&G)|}BBbW%`yuE4bn zz@=}ykBcmx9V8x`GF-s4QM{>s^D^c=at7%N%O3JvR9bdYH7UL$#N(b-W=^?Lysoc@A z^6aE8DIIO&wo{!iQLWU(7T0rAZPFf;H^+uzNK4oBW-Pk|)fSpc6sCJIkH;;(t{xS7 znABzjBT~T2vCfVd=_E(UtJfE{k-WrT{#G?@@KCU=%^9%(oYOw(njnH@kJA!0bJTx(Gava#)@@dXy3Q#ie`GNZ-A^;yZDlOgeTHru zhO~eX!AAjG4xJ?#Ktb4j{|JD(#l_2(Ki77GO7b@Rn5^>f@htBajdaTn` zq_Ih?DGD3BWiDOxMQsZqMNDzQh6!UuzQU~7V@-R^I~ zXV$+FWn=|X!94GC?-Ow+dJ7vkKe99;QFu{(S5-FppREwo%9&Q1MVmiY`s;wfENt>AExFefFT<)(+C^L$Ht!S2>!5R!aNSYY9GSM1w~PoD6YrbpIj^j;*CBJ8|3^n@klJA$3~ zKZ2ld1dfsbcszH01(;4zx*jGmM*~X27qn3Uxy40rLfG_0G}mw&=F?1g!eO zW3k06*8?inJ(61$JgPyfbHF9P#F`5+bcp7ga&6HrOII^HKCaUfy;Z8%X5-jUzLzbA zHR+e_om$!kT8X#VQZ3s;_&j&N;c3$oFyBOz(mGtll_bnNlKIC+@wL+VlOs6$Tb1lK z{&=|Fwlu<1_-^@Qr&^}!LHQk!MTz{iikY?qzbC1)d5u2hm8j+GxJN2>6nQWt*@B#q z*eq*bZ!Z1)`E%b=w_x$QGsjoY?txV65Q4d479QZ=56Y*FaVcE4n)6vtP?izb*b9p- zdV)eMSkv$UNadGgFf0oEw_d#nO zXehj=GZc#LU2j)7zq%3q()0OuM7>k;5C5@xLl8^*kncnuJW6ERD*5|Ojwuhc{GtjP zI^~yo>0H@eh$X zPp}c_b4B7y2iI+k25!exucW#f76**cggl>2qnH?4eLVlv1%$IV?9&?`b_VKO3C!_& zDJDGhP#ZlSh1y3a55Rk*B3Xuz^Y^!ME)x|46+gXwuFn=%KlFL^ompLAvgXsNHA(z# zM_YnHqL#7aUd(gQO6e}@HeFe8+iLi|^hg-h^lmh-)JQw+6|3F>d@!EqT>_7kgDI!T zD+jCtfPsE**Ub4iTa;*`mVo`LQC~WX-d<5lew_So<;52Q`h+1)h^h-}y=v>i{=S$q z5%jSuoH5A~XLE}!V;5<=Lve{R@5))K2yQN2(w|dW{5>ZMz!w=qvFSTEe9z6zP13ER zuB8_ipfyPIU=Ki}K?i`3SmJg-zS_8=NEo(HqH5Y@p4>bbp_O z1URuFo7D!l3Rd(^lkQtfL@tPLEH~cSPCLJu6eD@dR`YY0MNziy_hLvYMOAkF_dPCVcTb6!v9)!(i!P?Ugk9A}{JJ$8g zK0sIV;ks55ZA zq)DsFujYdpREgDPe)@f*X6MT6ryNb8g5@Uo2abI6KeeBBxglRRGVVyC~S{Agm zO7;JJ5ypqB!;!3irfq8I7P>q?QS<3z5#z#hKNksNA%z6W5JEP*aaZNcr8^_v99RfB zZ)I7=hqH)zDPf{7=tJI1zrvY-E(tg8hjyI1m1W}mJ~g!uO($Z1sdiOP;r%Xl?P+_1 zJ0AP%jy5W zG3Iy6r%)6F%8yZ8@li|}7mw|_K^Vud&c6_TD~(QRvNCh(b2u9>gpZ|5M1k?I-zL#_R{i{a{Qhu`M6wkFB$Yn{w*bRZY8V2wEiNk3 z)qVWrO$WXej@TH0S4T2eudtS_{J8GiHLk;;LfpX((A@RUdU^XExkE-l?3G+REqjp} zr8-w1_mg<;2`eS6JOSxK_74T@nA{>0IAx+N#(7QQ<;?SDi5Dg&X4S_69DmKQVLi3r z84wzF-lYm$7J4_dJcTD^K?E+skNTC6Uo$j}k{5BXGL&HCeH8Chxsv9o3f26x6uM^$ zJ~Jx(L)mj#X-!nH?BzhK5=kMh7^7A$Eu(19b=Hex@~R3{L4vnjz~+M_xZN=K#V6>b z*4Liidry{dUUn+~zEy^RaCT&dsnFO|3k-k9zN2!yUQ{hS%Nv)4pn^s2h+`JN^+UQa z$yLUvOjZ8Z3bm##K%r{>Xt7>g9tz{tV{}c|L=!W?a){ zFn+3hqam$T7q24R%6W#2xspxYjO)%?H~Qcd%0`WQtlOme*DK3z%C8F2f%w z!*$$kG8kMxl5$ zRqlW@kS5rh>+@qF|3LaW#X57|+90xC`|FC`F`NCiew|JSX-sZ12t{LcAcT%6X1A5C1CTb!$6W` z9aYLM7j62J^F-a^C?Ytc?VkKkwEX9%rG_mtc%{h%%ffqFIpbzz+edIW z>iZy9$4%=@Zz>SpDEzYLO}tsR%hq!~i71mQi!vgJ-_Flj5(wqxkQvMI5+W59)Jt!? zd$Ru%2LIVc{#j!X0lzOixxBal_T#|%V7dP0?VKVzEN?0}Vw&3Xw)$HMcBl-jAc6(*zt)QeR(B~=;~QLrA{DIfllc}Or^2z8c#M1J7;d6J z`L?&TANhG@5QHmfmLf4|`#-VppSYaCF8m_|qAb>GiVJnZfb#0iA(h&Y;;mxGt<0^x z?XC|v zfyC|o;=h!+qZPi(IV917UVQtzGxC1qR~l`)S37D{`v2Lt|E!{Wxwuoez^CrL6@D_m zIxwcD*;|3R&QBmw=E3qui;^@BWDIPWdkgQc4vE7r(0FB1B!U^rB-amNlu2kd_1l0J z-q3MI{4dudf?0eQ4`!z9KNeg5x$inFZj)`@jA8hpX9$Ikxk?71U>-Y!`><)9^-TrY zycPyjAC60b0i{n9*3#1GNXq>rtU!v4V>aZHD~{#kvebd8d`H~1{8!2($ngiYfB|}x zeIL+f32|&{2p%4uaETpB%M1mfSK8WaY^o{j44#|(?f_8qRE_H@Uwm18e*CbN)84P@ z;XzSLL992=TO7BaoStE|n=F4T^5e~9{g!{VtNhO_fEh2%CRoXjF;Knxx8EzxpdZry ztukHfS$4T%!_fQ26xU5JC37Y0b%bN)c2};3sI7W7qzS5{ha_)4yLc`{h`?=Zc!a4OirHR%`QvtMT{Q*`cf>EJ6LYav($9aH*jD={OW%Me z9gO^bzMwg|=#F_n#V|1UlnxulLRcoMGtr`YOs>N5gTR;7Uqx;BgcJf5#IMA)#&t-^*dr74#q)xTZavuNBj5>0WKM1WaAwR0|%yEl1;e;Ze&w z$<6;nFDZ%oY(QkLw)qExV?X~?m%IfLK?w$2uWs@i9>YtCp!+MJZPMdZeYxK! zIR5l|0sxJV@aUYPk;~1O`^uK82PXrucLhA&VHOh*zH)}Ip2+&ePkn7l*$rj+n56}@ zUG0Lbx9(97n{r~Yht?>lkM>CUEg@3Pf_2_v+d*10l?mS@j{N`$Z2zy=W|_>C;zQQ` z`hQ)8|JrE2*mj`g^{LElI#HpG<^Vhr1aH%!MrhQ1{tu!qA!84s#AA;q1DZ`6PaH@2 zF`(z3hY3bL_HVb>k*K_7A)h&8=cjF4SNx2v0u3QzN!6~D{5o=Oo%FCQgS*D@AZlou z{|e#j!~Qh>MpMQWESj)6*Ew&2xRS>G-l;AH@F)uX^YU2F0Ik5?gy(a<##RTWZQZ6$ z7;a937wD%P`gjUWSX3oEkDU&wDyO>`e7XDj2qz~pPg5XV-qtUo=y`x0{&cQK@>9n= zYg^lKp8=)GK4L!+Crs`*48+ve)IlO{%wi2(m@QvlbrMr@i*iZs$Ex!=VAg&;L%qLDj!vW8y4M6^$S=%)4$5q!jk&Hnwkzi3_k4VPwjc1XGf8#XC@lw?)P zk)UV$R0j&JjUQOu<}YBB62Q#h$LiDf>&)A#&!p34f|GE+2K7Y0r7mXWUsz8xOHkI2 zJ6z^3(a!*XW_YyA7M#77kRs-4+dJnCSgQ&Gkpzr|TtVDCD?bPqEWI4aCFFg;VR{_C zuHcw2%a$~C7fkM}3BPR#+%eo%8c_^H4+I&JsErNdkcwdWnATz%_6(~}xrN)@EabU` zi7?eL`jtO-Ej~6A;pS-u=T3Ie12LuCg!+Hi_c6G1N1k9AUOYmKS zfy=OuO7=PcbtsG(Poj0Af4wgV)S>g6ne0obzy&CsFn)s2ekN882MOgH_hIjIcawOZ z?$`aZc}AqWmQ>&Cv&dWKR#sNuz6bd{l<+t#gL((J?#wnB zuK;xjQXgnbl2b_we8A zhR84eqqZ`XRtRJEN1}h=1?CQ`o4g%~G#M;BLyE@|zf7RDIIn{sXlyf{eCRcYNx-~$TkC0_+wZ)uLC0~*-cYE{7mVjGQdy)hfqj0~x*~nK znSNEjQR*m#oN=8qcm~GPDEKtD0O6P*^80N(7a;t}TbLS178$Y^e{!r9<$AuBFIKH*-%0LRZ;K9< z3ty70D-_?JL^H@gt+1@kkGt^!XGi5;(m*+}`v;d&M)OpZ&o)neFIup^WEEZllAinK zbb+Mnba^P9m$z~EIpL!~^5Aa)czud-tUZ&J7JUppr{C;VFK57kjW#x9PAo7Kgz$uS z+tf3h9_Tt!(kp9bT=aVRSNandHVpMGQk@q;&as@4w4J~i+5pE_y#icNDTQ1AlKbYd z_r34;%SYxxD1DR4+wEBJIR(;p&ri!-y7*B@JQJbw6;d{ElVgheZQSkkKXZM>x19E{ zxH~f0v}uKiQp!I@Ly-3c%0~Q)mt~<)fRsa7RJxrlc*)5+ibjroa<@7%#TY+Xe!+ft zL)UU`I$|#JGOsPImi30XMc0)1?-(Cx8-aaYI9^;exPX!2C!%o}p~f0PM8qvCVnD_A zI?^nikEu_|CM~@OGF|ooUhRk;h3B}qI^RH5l$7wi?;kgCHRytsf{6Wf+O*BO<{>sF zU+oe?PuzQ)MDp@SZ_w+grdf}Trxng4lUZ_MURX3^@2?uAFeQV$#};fFwyGny2A^GQ zrhL5y8lQaH9WdKJ{y6c)(~21&=%Uei{krmS4kJVhtGj%NsAqf8J{j~?zg;L(?!tbk@d-Kpc>vtnw$>I83$%{1R@ccZ;;mB!f- zj|nctgU-&pq`#j|TBP?3XUkjF?PUE?!EH?*Ij;D8v%}5F?f1H1L(MOq02S>&)?Fcu zl|haHU2p0oD*lTNvt=Y)3XI3r*^6d`hE@M-r#*$9Xs~^?oE!(Dru8q4M;jBoPJV$e znNW;vwqT!_{ptT~J5#SC^{9YJ#v0r*A&zlLMK9<0!&#KcShcm85I6|tqp2jE8>cC# zTj&)r6}}IIg7pR*Y>~5L6;Uy`Xn*p{lw`s>_+`)*8h)Hru4BSJMJ3(B|3oQ7gM0GH zvU{=bMDY87dQh=>FZ#6A$gSw779z#4FC>0AU;b#zD}I3o+ZrnCqlsy$l}gF{nA{{1 zza`v!$DUu};J7cku4(%&y2|Zf3+xKRfctO6Y=74_VioIu|Foli`95pmT5v}1D^`jI zuD0@@F-G-A7a_WnYG1n_t84$TX2UH0NmLAN zfjR5Wq7GaB1kSVfXedLYi5GHvJnI#`Uik&~)Qjq>McSx; zpjoU}NfhX`=Z4d*xgGyGM^;~-Z-`Zktruj|PG_=deSr{qhyGS_#$c^@$FH}Xxn3*( zlYv+htK&r;ZCWr0m(4h$BNE9!7aERu-u_A-+)X{& ztQ^vn7*2Cvrb6aS4eWC7#fFgIGd`nwAW-_7Xkwh?B`-N(ZtzNRLj?%+k4SkcYTm|q z%Qje(9rd@4yn6m=6X^n2Dk8{ZCv)S%Axq5S5e%>rk#YCR1+Mtmi|9vV19NY1c!}f- zGb|s-M>@?=NSJIMZ#V4V+CJLEEmM8E^f~t?Lh*sXy;qOShioD5rvR>51fl4UDAkjl z#se?u`+g5Z8bA_QgzDLtl?0g&CAGS-s;0a(!zc_=e55qln4*`;m#ICXA~N$?piUed zF%Q4FzIyGUl*#mz_0V!*BWJ66+Lmf4tb)$DUz(b+!9cQuW%L+_w=ho7-il#j`k zd<-EfpKFRtRjL1)ro*#$h#0e)QYuPI2YWTXJscVMIcvHm&fZ9z9dZH2kkq>P?{KwD z5S{50Ys949 zQhvEu`b-N&s>kJwD#@EXf1zu-45Z*i{=g#KEkb_kacJX`nWypur7u9c4qUtsyYEUf zL0^BPsi*7;%M&ffdxH6EPxnJLXs+UlqG%wBQ$PsKVC4|~&iC_^`lFtU{XvIQ?acj zE#)5wkHgyeDWu-COgtl!KP&g(fdr4(+;otsJ$dH)!;9r*cgKm=(VrX^AFz0DT%Zb1Wx|Z8bQ_m4V98oWNTH*r<7DF z8da%v)KL_qbiEKy?8ThvC9e7PChQdkg-5-+1g;Pgac|+KQn+0{DCeBW8??A9F|8UN zgvkpF8IaHzf74Qke90tv)eN!vnHB`Q^NlVu6)0bk_MgfQh z;9h*7WX6HlSCl$_a?vaw%uTAuzkYsoLugnUIo5btDrCl6Wv?g9t?d^$LMYi~-^X5m zww#QmvV8K}QEe_AE0^Po+pjHv`g(M4|9xzN`Rbq{YaU$0_7m0WywL68XscX$^Uwu)%d93Dsc#uzd|e7km`IFRyH+Xh}z{su?j{-hU#`?D3Y zdf@T&DW-Q(s?&&~PUV577!b30ThRRNBL2)_S34i1qaAukSO(d1qmz0MmWF+zuvRmudo{0UALvb%XyZq0qO4D(@A%=o$7f8piHUN$?FSbTM^;FC2>l!q zF7=t=ZGHY-KeG#Fsp?1m=qt5#2`7y8B2;&B9s|vH??R9dV*JOV{j|-dFo;vBV3TS8 zdNkxXtqvP8W>TYvweyBr(I;G>*r=NNoxyhCjZ5J1)uT( z#YCiI6rI@P_uLqyKl8R>68$?LIo>MXtKhvX=3a%42kcYwt~m64+!M_N0}@fJu;k*4lz6S(s3DKijE49Nh?XOymbg``yGlgBg?9!?qklDrVY zrrZy3qxE%;$L~fScGXoL%@Sgk{Q+%b&t3r8A(EKzX%fkxf)nwyvB~51s#nCOe7B65 zvegX|1?Eh-g)K;mcU#G?H+hQ;JoQP96S2x5sH9scX6(UV9iUr4GUqFYRrXs7$|4OF z$7;3YQQ*kDrfk%wMYqy@csbwXh&-)y_hd*ybd>6X5C)4slFcAuoYnr;S@ zr=PutH`u{uHpRUX2lH?;gGd=%dvXO2|M$`u6pZhpEvocTr4q-#+DD%b6RLZsVHz)U zrAd1jH|@3&M)F5e3Fa|QwA@QU-dVnl!sWry_C;~t$1WDlkYo@>68@7sEtoo=Hs0Jv3#GRoc z`UeWfMw%EDmtYV>;VA_~sd`og5?;ha$ge$sXJ2CxoIZlIDy{qOs;K+e5Abt#IM?Fo zKIiY)!*tz_(j+`}hp5TnZ58ngxHz!W=2oRlmj=+%tJu!Je&t90rc$_0?ff&x>zrii zo5Z9m%DcvN4&6+prX2@vfN2@hjZ_<=4KUvt7|fo@@b)YC>@6F&q5&E;O%N{IZ%CHh zfWv|gKhW2~fhnTiMrT#Yg}PC%-nEO#Vm;{nndv!<$t~9XJc|3Ui__u-RNo)QURB(U z{GN4z8LA=NB9UBC0$-`2?I$+IN&QkA|Ilp8Z~(Gbc@7gbavsz2mTqDsV?~iUpeFvV z<)^DolH@ukR(E0R7)aZ!|19*Me;wW9Q;1buQZqYc-)No40V;Zf-eY!GIViL=i9`m; z-o6gpO;o+}D}-@|9tY_sO$KMa8!OMiq|P;si2(Kb95pXv!&F1bD+r;_toustCZQjq z5Kj8TYB)=-xe_NXavw^5dur?IWUeMD-44_+nV;Km-RT!R?}U-$2!=C6)9dI=QXFN7 znf}P3!<8Gw3vrm#{)snO`v%aU7!>D*&gJI@q=svF8rZO0tg={%DA2q6$tg!;3~H-+ zX=wJna_Yw(QCxSBPf^4(*%u=rX_A%{GU?B}z33JIo#@h7#tUQw-?6w4ks8ETaEAzv zzbh-XtbjEq(XjbdX7a8^^6-a@w+#w3r?(-5e-yWB5QXGC;`?x^#gNa$Y*Bq~jB{h{2 z8SBfkKYDjw3o;!Lm;C`o8ZUaU1uX^-_18ljGxzG|PP2H^rxtjVnZ!0hsh!Isnu2iIU+YqS>b(0LLH=F1 zMBx{rCTRQIX!k>{9@%yoQG{#L@zoEUvS^%GtD91%#79MDy-py=*O@JtI6tqkra0`^ zAg0ps`L5_ke!KO#d8p;W_lSe9AM`<|+^b%YMPJ?MXflnwR&A<}tJ#SFIAbdI# z?;jQRd%wWg7ynRyrD3ia>NglA>7sRkV3^YBZxNcLJ zulLHH<2EWzUs@PN?p6adHH!s<^7*4}H>7osRK#k-X&Jfh)W9pKDj@FlpPY~aPa6UfrJ$BdvqU#x{X`&=%Q zQxh4?*|(|JV5M~&T4%{GpLvjsqw@_7MG@MFmfMx!nPA8`!i+g%Dye#S#l*3mWG3p* z+on&f8G!?Ltu5#>C`URx-B7$&Od=;Nds3Ib`~=L7;9~sJJnvWp zCEQ+MxYKC4jc3Sh%DQIMALfojnt>z+Go(-!3L=I5+?Jq-7^4bTa5XQ4#Du-MF98EJ zJ-mD^9mDEdlVcmDtgxqFZ3rK%zEcAcaKWUeER#i``vJtd`84j)=pmk>+NjctTGJgO zm0aI69DcMuha0@Yp|a34WJLJv#&Ryp$Hvtw1jQe)b##Pfg8GodyW21CeD!N!>tI{5 zdPeg&?(-~;7FO3x6?SWG(l8ab8=5!2GH1IG%Y#wcw{~>{#2vGi@LOVdQlzD-(I=-- zua9NU+<024t*||pS5&|7q$@)DIKgSK=^++xky#VgsXDK%3p)AAI~TA`p3@n{-8VOM zyYR;lEUfS%*`9X|$-oHq0EA*y*Dw^tBM|qBntN0~D~J33Q$NkvpX5>$bs55CC8I%< zu^D#CCq$`VrC4p}35^!&j=!(Yema|YmIIqtxTk`_E6&5;G4U`ruh2OZO?S`tJN4#x zl}fAn%Pe|9yr`4YCh2i@89iZNoybjsP8Cntx-7y8sdwiaGJYr<{vust3EkLti=oPM z2ji%p4-I0hMo7|VBv;mb8gK@M+tHdIBM4=?7xC5z(Zy@YceE?69>D|=yf0OxheD9&8Zw(UOLVvsbYTRcvYGBeKAa(x>_7mu4rYGvJ`(H9mO&ZvSA zrH3pH0gh=gv5ujTTvf$+Braf+U=*q$!iZz?wC{(t-54|Ye7EdrqBb6i6XLCt6E98+&PPZadY(LXdR*VXd7h(vFS~9)eN6 zc`2vrQy5M!a^b#x-x~9QRl9i?W#+Yf!jK^HwZpUGuGU;;wb1YFT+R8c>mc5BNHcMX z)7Ii%pVnGF58NWe2Wz?V64n`zt1XHd{y-6><#nET>#4xgkYwXIy?W=6J!qLd)j!A? zH^ygV86^91lss)qOO|d$X1I8}4#|aP)ZxV9UeF-*Qy*s-uU5%wxOv# zG&5Il__%*uc+lETDA)}#iQ`P-!D@rwlwC@J={CeeeDS)LbS)LcY}4FN^1^KWmP zg0Ky)_RZM~kE$$8Dg-uipP=<_`=>pfA!v<8SK@Dabsn9%wrYfhQaWRjsH^cr+AjM^ z?Bc0gPFVT1<2kLnY8OLecLd*)$}qu-wf5~J(+ESF-*MF{N3~<3!`n$OyP+dxY@Pe& z8E<$pSvVHtMCPt2k(pH8()id}s#bP_QiX9p8q;u{z?zm$Ro0+OHu&bhSOCL{(|9>F zL%#+E6=}7u3X_?jS##q$6E+r3cKl8_{q|;P-cXplM+Yu#!|2yv`)t>In?u|0j0|3y zaqnYd9cd!fT_5JmugRl}9rwg?#%Mo28v8U=M~t}{w0*3Vxvj-E1q+uW1l6}%%}SO3 zH3)8DsJxT`Qb~XBo$dRD5{m0{qJiS3fdy4RlQL4LpDQpsC7Wf(Y6()Cyf3OD3%sRL!0gTjT^m!#jen5Un5~OSE7Lweygf?AII)S6f{}9E-S$B4XMbgkPlYgI zJ>Ik8$!sGz4K<2pdb=x%^3n%OLIo(ILQ8{@Wk^p59~x{1Un7+oTubc3KYOyG<@F@W z>TQ(9m#3Vmv`gbX`uG^Rgo7^?M z0CBSMX%41&VwqDj0!8)vxv?Y9+YXhxfib$jX>!vF^`Oc+3vx_UzpC`n`LYpM2AQ}D zVb6CSHIv%t6cRHmGk6F|!080)ES3k6S%{UEq0j?#rGaHz-wD^RP6C!6 zzuoA}z*cDN9NMe%%BnG1RcgM*ScluA6ZJ0U-q~{(9P)^hW|#bDNKMF$V#$Tgeq%!Q z2LPCHap(7vra^@&qwowqQR&?%8iak26ulve3j)$!zn zR!zB9BqSta^O<+hTF%!BEwANn18ad3?jU}&0)5wTv*{~CwZ~8>>*}Z~j!H`s!(R)e zIs-3z&G%?umq!3kz&!Nj&4#g!%wEvQa~zM}so64SiPbGYt3)Q}+KaZxlvCCTMYF%= z`Z8UZ+4h^NEMohD?1fSMGXn=9w#yihb+2LuyE}QX)5+1)FWz}qrHwSzy{jv^vVXTC z-WrcOsXcca%6T)(4|UcJL}Ka_P8UxlEZyD8b0vuy7=a3GO3ASHXB4%f(sSIG^zBp5 zg9_Z(yt`hD1)Q^8FXFY7F#KFXgyj0>wK>6|e{4Q!->Sy_1&sz`&C@jN`@dkewma3A zn6=Oo6i;DpIg+dhjX;unPnK=z9#&(3nJm^|q!Z&BG(Fxbv?RzMxagG^`=E9eNIGW|Uoyl-B z+#}*vMi~mz7~)qvrm}4;iZOy)BW*wDyeWqg)V(aFyMMGryHtn2PV=pv7P?pb9#3o$ zo5K3wiqnL%uU1{ zE}d9vNsa+JLG0%?1n+*b3*~>VD}C~!ViE5)k{;w=>V$lmgA7V1dsS(``M2b41?F54 zDlTtOi;FS~5U~HkZ?}$v31nX?DNR~&ni(6^=(W$Q?%QfHDX17)H>g(<<-@Zk4DVlo z*iJe8tn{Rw(;1ob1MQw1?~?W&4<7f&ItI_6GIr58J?2-wKf>GPkjz9;2;4Yq^%n@I z75EU)$q^=SL8`cQO7m==xk0A8r3vmSofJqPP&aXOl1IayRbvW&3-gsGMFR2JFjDoIqJ3cqcPT zE06M5^_(m(Fh6`5o7PQ@1@YubDFoV$8^!UQrM*WaLHL~?`eH5bCG ziEd*{LgrJoF9U5B){oV3bgC9hH14$8s}qnlCYpB((>VRjpGw4 zUMJTspUjwL!L!h~^JLCrcSL*bn$)?uP}ySd*O}Me`T>Hw`C;i40e*e#-*``oz!~4WGVl5EK4tqO z0K$f%qpQ$ejOIKvin6t|Csen{^R3XPza4?UZcbeU}U{CT{j@n56t$ie&PHn^3Bv~yGpLE;-<+h*{3p6VLA$Mb zt`B*i2Nzy0*nclPVFu3mr!5AhbRq)3`=Cn9McaHXiT)iR5ayQ=v!IHI=;H^(y?;o* z_|1z!FMlXQMf7m#-9e*=zvK%&Zg$OVRSgWIxMl`VJ#!vu3DEA-bBIKRtTH|fSI0gU zk->aA2;K>MqD5SeG=l67p-Npor{07z-D|>*cY^iJO;eBUcGCv@}sGg*jI3~D_}@_qta zMCu9BWE&8H%hOpje#Cdl{Iz|a5kqD_KP>eRgQ{;pCjOG)54dEW*SB79AR?D1Bm*5# z`BQL&%`rKYeu=@M{CV;frjllk6 z9kjrxf!C_>P>ZNp0%~mgSDz9m-d6L+JVDSpshDb68~clV#LY}9@u09|j4f_kF1-KcuIIE_m&{N( z&Kt)s6(!7(?@$*vQ%j;Z!Ta-(KD7DUcf7?DXF%oMIm>my{IT`m=|uRJlV5bo@GX0| z_jb$F3CVho z^O1gyb4ceGr4e>#<9DBy0~I-*zdeuh!o7~l^Co5P#c}|TXCL@x3E|=Bd`6{Vv)cas zYcl-xx-1?AK8o~_cj()xyGxMaTQEQuXl)HzJphLPw*vjUjR3wrH}pPA=@daRc_h%2 z4_DS|6yCxs&5@m;&mzL&eTEUm`d80^3`xQp|88EU^8ms3`=0Hm!^YyZ#q^-bKK;2? z{Pou17yqa}nUq(8AC6z@ZIdsLD(&lB+kHTs0KTWbS@B-Ke?t##Xx}*TD2e}Ue*3Gj zK_)|3tuQ0>eq>H0(@S{?h$a-n&}iy3iNlq?0yKP`+FQK&08|L;RG18joGiA3gF|UW zg=So=6M@sjZ~)SD60{sxq3n-_m&4{At2XUkvqLU0qR?dVA}4-k$h?AoxJvPk4knlF z;}`tm-KCi_?SJ2{pMXgtEz;n}6^a*pn(0E1_#*EfWOf};`n<)l3`AZ`nN?5RV`i_M zMPG~oD7DcDbY}qk9h+0#Ai%Y7M-XD`pU0Q{ur&{*e&n2MM=@^T3s}!aDOH zu?-^dnJ*7^*S+8;*P(#UnSO@@OLAp5J)dPS@<5T^9 zegEX#nIJG~b{+b}{6F*NOX2!!Ta>2dMAs<^AHaGCqowLPi8(BI)T?BZY^-|7ko<~a z(>~Z5Hl9fqbNO+TGv)lj=6vRnP~S=T`-YRFdo5cZMEEQveF61#2BJf&Qbk~aOlJ1y zi+kIYArJzNm7E}nz?T(-oCgYf=y+uOA!J_eNA>`^Tx{J#&t-5AM$T9Y62B6{%g*ty z#4@R@!T^crUxwV|8`u4%{s3rnS zavQZCi$TlTnB>klTaDY|D?^H^%QgyoNwz?G=QE1f#^CD58M^CMwQ;=AsY@CU_g|L~ z)pw{EEccTVl?IZ-um!P<_8L6_bB8~wPR=k$&lVLFxP^(84pl!`EtHf(I@12Q$hH(W zyp*>dW$4LIh$8aq;aGXdv7VTN#37&49ZC9w8ffKsO!lyJ_?7p2C2s6k316%S2Um;t z-2ejG8v7kpjN6xWl`pd9td@3MDop%i?&-`HZExDB#3Dr0@O=6`eSGR3!XBd039FT1A_sBuN##>m|xp772PP@@d!)Va6l<%SfS%(2EpC zlWn6PwbtrYk$bB=^h(v9HE-y2lmv_JmZ~&m6{EBqKG;Ec=r5vXIA!IYDC?yfo~c6E z#~LKV5aJOY?p>|Mqsp0P5vJSxsAte#ZCuhIUS&|@^XEU*wb|qyx}r{AJw6*as>f~H zo}ELs_e+mO-q6Uz+y;6m&Vur5=a&Ndn)1P{FgNsF1ocf5^5mbpR|V!vKZ%zhhAYL?pY`zc!^@3K6VrktAF*_hLGUCTkA6KeDCp<%BW+7`{*SZ?IRh5Nv!l=kn^+t!Ew~l)o&!jLdq^$$M8(F0)Ec>i(flSAD!y zS3Hl0ci%h^`ZD;!&5&egR636vp8thp=5H`QW0AjLYB4Oge!etP_S!w{hX(nxo^)^J zR}z0kLWBkW&Mf8%b6sP0e>TNEbt-?Fz^ml14RP#iJXciy-Jymy6i)=TTtNX6nCb|93L-aB<74(R7O1t6Z@!aoaHYDF=|wzapv;JE>cdMb29AaUid zP`fw7fB#Hb@$sdzpN;Fa+fjKC{2LKq2F+~R($Ue^#LbHDz-++L3I0lIA;3+qmu1b? z)K1!H`;c1gI~0%`e^HR%-4cU>(V7)J>e9gARnJ+Tmm%JhJVboSSI8$7s zrajnhg#IBmWb-=Z=aY{RtxsLyWIPD=@d+`d`cRCbJ_KCdjqwBovhKZi;4kkC0b?2c z!|N|#4X&*apJIA2&I0khJ$UI?RP2fWoO&O~M4u?>?cV;S0l;PLi|+>vtwg(~4HBCJ zysu51YEgeNe-G(?0wcC4(yMEjhub4oGl1G#9f_{oZc4`^IgQ=)0Fk=Hc5>7+ueJ~i zlrr3%qb>q%Vt@Z|!R13lrj1m4K}HK~ZMstHt!(Q6m6skjolLKSXPaMpY3UTjM~|zi zTS=yjh`MtX%+O|F^WZ@ch{e5qh~M>Y9V29Vi&WKqZ^rc*#M@Ky)Gx_jokBf2!#|J> z4yts875yC47Wf;VE6{rN8 zf#SHb2Leu2>OcWqIRpQ??Vk0e6rx6~NYtG%cr8C*1{qVLh)^>hNu^zdT~`P5w9}{2 zf~Y%HBG0s!VK<3`Jur0%D$=jbu&?~MJOBOXE6-$}0iFA*IhMu*XY!=67A%FvdvtD{ z8C|EaYNV<`Z$DxxQ=Un1Oq2eDuLc5p-MmU)a9c@jezbgAeD0iG1OE#9fyhTvY?s;Y zE^)lg2<*m|2m;wv3CufK)Qtd5KH1u=>QndyhsH#vNIW>bJo!4_ky>jfxvaPy=)0a{ zsM7GVM7H&m$}UG6c?Hw{eoo8GPj9LZv`2l=`C{=%6GulK8xH~{7e>+B!5{nMyGjK; zr~FT~Bh43h0vKN9U1wY!6jSTFcJoif#gT5o%Ar~4UIV14YVm09bLIr8#1emt7{Ba} z3-R1_L$cmH*)h=D%+yi5b7);5UlN|^%OWDNl#O~2gw4Ro8BEspUq}xg;})-Be}qhW z-j296=Gmva^{b-h%&bIwPfVW&fSxURuZO|QrYXI@J-t2qVX?tB8FZefDm!EGPEe>+ zSN%CxbF|BE_9dfqJDa1Lx8FmV{2258w8YZXm6hFJ(?TnO#=CuYB#6h{h7Db?bhvOk zEa48ohmCny0REr){FKh}@^ZM5PK4BcP7(7xuCR{5SGQhJdtyXv`m-9RufNG2uJ=$s zrPHeBqMtGtVd@uS`qP>3TN2a#Mznv++UMJLB@{a`A#yqsCTjw0=#1&cE0%UhJSS|Jg#VUlA}9<%PvrctX45m z`@RJ=c-=&yxstL`+dSQD2d7gf4i6bAU7B|4us6Ft~XaSVphJ1%lPZT=G1+!2_CAWIL34Gozog<-BnNzLY z=$6nwsq7YCYz4;a`lS1q!;s5xSNN6h_&qyxUN%)ej+-gh<5rNCr?2%s1&hH^&D^(N zy_4#p;ng|g#dpce=2QCB$H6Pu1+lBWC%L!0e@1gduN*cW+5S3P|$0gxI+$oJ^AbGmQRo=GM zCM5iQK$6Q{qaFQF1t8Xc-l8>X%+SWf7HQ%KV)1TjT_@#6)Q?a3 zJ~L~pUsOb7IQe`&kFR705z$<#vwT-1C^Go?Qi*ktElPQ7YfHB$BK2`@#>x1Fy!8s#P zouV~iJ%J`%366z%4#~O94OsQAH2d??#n^d@afTm3sF<}Bp&S?-9NY+cxo~2-TnQHM z6~Xi4_Aqw%;0Z)s8jS3VFEFi1x(Ur&XWO8Yrh7n4{n9L6quON#=#|D{X??coJb8R{ zpr80WH;h@b+8R9s=O@j7A>|?Q>f*o}cfn3Wh{tqqf^8^ic0hOO_`qI`>-=|*IB%cR zIcZEiWgQ=WyF6HcHn!P)jaC^Wsjl0PMgh)Bj4fA{DoDEA|cfKYj2?PxC5x?p~f z_Zx#r24z_kiswQjid`sI61qm{IJcqMpgb-@HBQe|UWl(@eT+%6^3HWj?K2p+k0hc$ zF4n7~bgaJ@7Sg)IjHQ;R*fDp1YOBM~}zz zY&G9-ag3qN4fb{Ugbxegt5N8tv$6=?7kdEQmF97 zDJBkR!VG+;cH}Q=LX(W=HMYQL+m0?jCOx~tu%ETzk9|sfpTWXz&XKk8LlxwmKNiPP zXW&Q^!*-|QQ40YWpPjcIpbSltMYs7%gQW56YTYJmb2@og`(mP{YUs(O;FF%pw9%bK zAZkc)lIkw+g8*YBqQ?GcX_oBnMYK-XsJBYu&n170M)N2~YhvWJJ^S)JZ1Btaj$)Ag z`X!=zau&4KyTJ zp4lRp&ggPq^0=e5j*+e|-R>b5+XfL16pKOmBHbLZ>P+}H*Kx-l)}zMH%|}SBKqX02 z2-Wxc(tyk0veEhr+}KShmkG{XK^2d*?|rshGPS7arwim)B(N*^xirEugtQNV`9Nc< zFlVEn3F}Q!;omcfeM&3(f&OJ`**MozIwCkauduMq7fdQDNTqgVs_7J^2?ge5UNr)S zk>7-SKDZg#ZSv%5iEmBnYH^?*&ljnbk>n?=+JK#MJuXK@KWn1o;`J`Qy zS??}6*ox@fx^*jj<6K9(gTC;%meMgG!!^m>t6Jnpr?DKNiKoM4p}3-mCeLMz8(4da zR~o}Uf4xBzK?04(P8mLWU+{o#|A)ossbb{{Xpd~h^7K_woe!0*7cBWsfDyUE)@VC; zI#k&O3l{WYRrfCcfmIx^eR-YU7=#;C9w^bN3{l_(&{=}? z2k{(iFEe~W=iT|pildIDgVa^izf61OYQcaCn_mv@>^0C9mLE#jV-1TvJ{(s{6s$b7 zB)+DQxc&6gUFu?Ip?t0<%C%r&5W>&%!-`=-x@jSbg~E=Y(RSd!Z-~nAs+q=9@Bjm{I)iM~Pnd`D05i(jIPftE`tU4|f=seNNV(JJ+(*owqzt(kD6 z;x%5knKtF%*<%E;TaNFzMgSLgk3-8U-uYS_m@L_(5%;rELofLKX}~ab`8*>B$&K)+ zr!*~$zAnDp>YuyZ<_T+h{$OtD9yDEA6s*66RIDvlOOJatG*8NBzZIlG1H6*GjoFSj zw_mr*hfrr9N+Px#FNS&>ZdHVbpB{GT%db82Gy4u~D)cBjD3^1Ov9j@m&Q??hOoR4h zeH99@{;;9h5}04cPT%Nf2=AtSgj+HiJ4k>yP?W1;&69yJ*LCfjZgOD$6*D(okVbul3#jC z%Vyyh1b2#JEgyo22C#JA67$BCVZD4bZ{$@3nGUuIvf*)$-IcHBcg+hBn7cxV>Ztel z0I}~mq!Xyzhe-1}!FMtRMzVb&kSntSb#zkh%V6DgqWZ9D@yJKspz^7>Ze{sBWtLi2 zfeaB7jT=_5W)r5PvGTur3^irtIL5xLvbb5cokVJolOLZa7GU%XsbX+SGf!@7FO@ zBp5f?cCzhZS6dBsK6-AmKotu0fIBS#i~t$NBGOJ~L%c0`Y`l*14ma`wacqcyqY z$D*{z`tzhqJLT#h9^fK0A#X7B)JuPQ`Wlq4kDqc$x`1XakNM<%-XZgW2dBBY>EMT- ztfzD@YBbpfY}H`Z+H%p>1}yraL+BgDVgE5?IDlrJ@cIsNf?|znS{Y~(PR+DFsTd?6esw9 znw3FCYJ#3}J&*DtO7ata=~`9pAvSNmu#UbOI7gkVQ;A@LsB-RHPrMmvhJ0H+M;2cgaxY5Fhj!3CulLZY~yd-7uZNd>P0kY^p z>S8^?kw1>P@r$q6u-D!tFlF)Le42|Txe=`?9aj6+ZG3D-fZJA&VkW3EKfm=uz83f0 z*pc^|&av;40;~*23{QxF)`&|YbAd(ilz2C_zC9TM20#OSD&9(7mO}|@I1nXxTJIsm z!$X8NzB}?}^APLOY)U!Rq+*18Bgo`79Qj$S`9ws|L_4HGTqr7xaRZ2WhRFofZcrPz z$9i6fs%qW2gY%3|@l6S9+C=f3{Hszqs7-0cp2Vv@yu4NO4VFRzVPA2x$Pm1Cxopap zWxNy)rAAHW!#LyImm>!`e_4t0j9p0OqByKE-TylE3>7jJycRB5OqdPxHR|EyIi9@J z{CQ#(+FCItT8u`|=?pRqiu>Z+ATeUXWM3*^rUaUOI03)7IpVBw@fUKFi;0Jz!_4=0 z!GgiB>LfSdK8T2hjl&kuzp)O0O+~3Qbl!^em;|DD9$?&HTKr@(dEX;8o7}r{Bw*Hj zCEN{)pL@RBl!PYVzV;?dR*g=<5n_yU_42FyHIU_*iAhty9^c#i?Is30XCS6kWg!tI zt&XkBr1(m62PeUfN?_!szn028fIvI)krmUcphhOOL%q_RkPh(4Ejz0XNM06`y*N1$vV`wf~jqB@sMQiom=|+F-83dSH_zpJ`S5Qz; zA1(&CN=rr4F9f~pY0*LKMqqnfqV0h_>Fk^rxrs%@2mlb@pX`9i(FPz+h!AJi06(q- z&O`%3wO*jZGquRLYe#y&fgYU@#vFI3HRxr>8g)OOoj%;#2-7`^Hd+ustvUXIVz9C# zZzNSD8j~Nt(6DH6rc)6sZ<3%jIKQNul|x_7z+EwPVp+%&;=ko+iGM$feG!LrPN6bH z`E}GSjmo%5GBpjWd0w2bKtt}e^iPZ%3N&_;H>+@?)JbPY`ZGEK;* ze7y06dJZ)2E{K}5S5DCnnh8Gb!5s6`DnMmK0JR9_2+m=%>IzJn_a(mzO|1^>i7)1x zeOd?NECvpVd`dN@92~r4SnWz6EM=`BGPjC|1z#wLjvgWyb>3{8Z7co<#mBORoM^4> z1aQ z*@7QV%Z<5KcZpj|ZNZ<9^KR(}y!`Rz)gA(fLB7x7K?1-t?g63uuq#e!`Gv8p92+Hb zt148%!+?T!9b)&7;}p3UC@caj-(L^~3#wLlMi9gCO%NZI6t7dpg($?e!xfZ?gmUM1=)X>GW~!v+_MI% zf_|QdO6pZzW+*^Wf00C*bbFTLQW6fCX$8&yFiMkzSW@Y1zA|6m1^iq}Cmx}^i|FTZ zH_c_YG)$r=Bn01$ZQoQIlyrI+BUH)RjlySt{H2h0R!b^P z0*RdAZdXn}iEGT#Ba03rX#AYYHMEJp%eRhxnd?SilB?SI>ioE^N*wFu z*T0$?IN!F^hdC&PYff;;TXecR-r0L(tQl(s1M3galG;6xy0&+~28fy$9nRPTEpRQv zz8Aae)h%uoWzivrw-c39Uc|O-%A~@2JEPt$5n%t&t#w2Bj5p|aSFQTZt5Z80*O`$m zh0Q^=JS%(gRyxclQsn?w<@JZz}OB%iC} z$SgNH=~UkpnQ2|$&21vYq>#%Hh7I<;&b|Hps|H$g-@bTFFuzm`xp(^iy!T6`#1|#L z=v5mo-D}mH|4t>q-A*yaJ0ab*m+!YoS@A#vmLA^50BqrN`dB0%g|;dcEeBDoU%r9c zBhUN`hswl?Yw`L|nFZwpx4vFy3B{w^>qY=!FW2&_M2A3n}BltUNC+oYW-16MQZBDOa9X**84gb5(z5T@%4T)ISjik@lXuY$RhNVjrW{Jhd#ejp;M z;N&o!qfyjBaW#hte^N*0onE_4cduhJwcEGZz>>jj(JPEeLdy|Q(NgUqBit~b+qa|L zCP9BPPysWPfaqNcI;CCjL+=tB^vq`ucebBUG3)O?z&Qy^b;8uh(&zw%#t};v7fkV+ zyW0RKjK5}V(xt0*6)uz=r@s9U#smOKukEAk`9E#FYX3dnUlAD#s3c2VZ_@9OB=*IYdwox{>Q&>4t`X2{J@K?1<=T&F!9l^v~On_ny z?1-ZgBr5;DJU>n?g{_Idf6&wJXE%)(LhtNAO8F-e$9rKdm;G7S7(p>HJ`iUA0rOn7 z#pvqzH59v0T|1)StkxAU!TX(t_7~YyuWkD1P|Q3~{U3W$8Im8jusc5h44f5Cq5pq3 zLz!A}QN6pKwNY>i>t8n1zg;t1U8uDTpBDYm`VV*UOad`M!w>;c_xopmUs*azS0}rc z6|AZOwFCMUip0&)D5Zv1^Q>mXdYP#{@)(OoTzGZ=W}VbfBr(p^kd*(!Cs@<|`2%;( z`}$n`L<7xde?DAjyb9xl*!$Li{OD?9u$+>AYlF*Q=9K?&ap&lBF7@#u%qlA z^)HD4c{leT?tGKt<9qdh_it~9vNonT#%S|Thda-I1&I41w`jNptS`Rmmj$^j0HpGN z-;<0Px9MzCR^Aum{eSw@S8sVu@joyYGHdgHxdZ=x@YcNS_T0}kuKoQnjU8cHU(oy|G-VqPWG^f~J*XPTJRpFpL%;m5 z(F*?2L$RR!ARdJO@rDeaO^W@RzJ0Ti=YM^S)A2&}5{nC3&;7%-b&XN1sN+HC*3|1jh(vENfQSB|Hw4fr36SF~;86%yAAtbZSI^BRHLv3RvSl;hwTT*!il zSQ!9=aIDb)5&ku41q+Mp-#(9?U^nld98m-1kSs=_d1&svtJ1PORPbUt0Xa6r-RCr& zV3R;0B!bpwweK84E!AaE>2exUS%kQ+7Fr2sxL+r;4(nPmjeu_+n^d%M%aOy0{ks#l zh^Gi&r`{*y_FU%g!zVuAZM^MI&Hg_x5AoqEA5-G1i;3U33jOrlvwIK#TIlQRtF+*# z-7kagx(lzTS0G{tH)Dp3Xmo22f$jtf0W{D*c=z%1jVD9+|1ec(%HqvG zxsYSs25@ckZZ<-e2R+Pjh18|8#dpXc?o+zSis0Ftn zaCVJUEuwuP9P_j5Fd>b7Gx1A)qrU$&8kctLg3zm2qlhiIJaO^VS)Wby_NvK;8(obp z;@_XJ30?~V1)HbWNkUwlv85W0V+wi+jcPpPuDHn8p)l>`8R!eHhv_VvW^Mlx2$c6;>wAd>v;C zMz+rB(<{J5hnqn-=zhaG8pUIP2|C&FCN|$j92nOj#D6gN1HzeTNacqMqm@5(%@nF}Oyzbh7(-*>IlA#@G3j!kv4w)K9LL2DNOxB^lT`8OZ&w z(e-!+mUOgMKU4&GpckI$@k%!ola|HXe*DENaY>QHaQc#|)SD=nva0a~aq;lah0v{y zfXE>Z_(@P62^R09ovE+Yx1MS&zk5%)kjWpyX!2>=$!<%whJ~kN)k%#xq09GZOIz32 zc=g~5(u~sX1caqo=p};UPPERNY#?6Srx2Rgj1(p!PgV$#OG21n=qQL`H!57_8+!#_ zs{gY$hP;>HEWdNzgWce(v}?m*FWl^VV~=k^F&lMYyiyb)hl)vM~38EJ(tC4_ivnrrfw|<#eb2KA@P~?y2VQ z>RUAK)bI~hke(9;z%e$jpfYJ3-rkRl$IKT1r?3`-8VDSA>c0SzF(qVD?E_8gpA773tm0@ZL%WlU2__eQ+)~_r@0b zC@fW4nvO8eV{p=6Yd@)LIRvn+Xly*%Q^o0t;8m(qH=XVhx&w%3BuGB$=TbHo20I2e zM24;05l>fFDD^6;VrvHPe1hV?HMA6tJm)YP0I&~vDo ziCYH+BVPLCu&mSk>%)z(+Qq_}e1iJZ7+jN0m<%=B#7f%x)YO~z8Kl3*sn*Rfn0%YO zy$th{2uBy8q{Qw`)`sry0m1bHltLztUxECE>|P(x8j>f68{ttVgJ7_E5y?W@m?gbD z#J7P>`*x)n0T~8FkZw-r?rvb@Kg;yi>$K504RGMWNdPC}ydq z68sm08?nx4n1KnosOO{~LVrBuFt7ghwOeeKQ32b%D3Q9==-_(@-$T_Ev;{(>(lw#< z!C03FuQ)PscP=wRJp4C?2F`N6P|uj&hrBWy2!jCM6$10wiw5s{p$9@!7XDQWJuK)EJ4cwQ1zW*d7k!N9JUIsgNr)a^1hwnbQZqJZZP)9ikd&#>jfMnN?D8C@Lt zDT5vr74Orx+U~fUyiLqj@racEm$Shp1Nind^*cn^*SI#4>m@+b)K!okc$d+_FRzj% zxe8&>d=#7MD5Cq+P8uXUyq85qttQeCA8$4HH}ossd}~KACS&K90B9+1pGQ4Zi+VDv zAg=SQ^dkt+-u<4Db_BgYsxUdr&i?ptZ>VTxUQsUc zCgy1zVf5Mwkg#6oFc$YNoWAdWW7&~T9_$QDFi|f&6E``S(t1dO>!4m_BP}6#AM{=t zo);`OCr7J(Gw?CJ`xxA**P~$Zp6n*A+&|b8X1TTPa7LjfgD);#V8Ul-B2`;KE=}mI zk@noZpifx+TTxi}GHI2FNplHbx{(z0yXK%AH9xvJ+SvS}WWdVbEYbCxiDfFOgK(y_ znKDm57teu>Ezj@dxbUE9+Q}2@Ji0T1xg)ZUUxwFVb&H=bZ8!#O)UwtXy`~v>EEL;a z{b}=M$R)zhH0npD8E1M#k%yBtfSL@kCFfgA5mBZ6f~|DY6y~S}b<4jpJ^}4#DgR;t z6td0FXqrr3cs_S6Ox86Z;N~7wnx_+f)PkcJ;$kV@3}DpimlGh@@NtTlvbl}C@)$jT zJTHvaMqT2I7JRFm3Q_Ne+kAYRkFI@Oan;HpU@pD96kPhj{=med(td;zrDtmZwhW1( zEuTbgAN)X_&l+Q7D#tBT)Lm1hhp10=a?bMK`%L+p)XrLIy8IWn; zNrIv#H!(yk<7Va0X4tQh@+gdwjF>N6<_ft(LZRDWf-l+CU-130Gq<-VW$D$!IQBPb zxN#&V`)C~uQE!%Q>$?p?&uA44d%vaJMZIz^_IfU!<^F7?W)D`EHb*WJw zXP(;UUnUtrl5x)a|Ct<)%2^G?;_vvddhz928y&)N)E#=c6H0q&3tzM=>`9(afJvg2 zZw87ZJvYNj^OaAe{~9bKua-7|JH<_kDS%R#24^EZ)Q6_Wp(We4*+-2z*D|HbVFwuR zeOtx?%O-TFWlbtq!x*exytMwux~5HM^K63A#p%(2$8?n}k5{?)6nG_owZE0J8ppFw zXU9#PU+Ey7yd|XV1cBq%U#GYyP3!b(N)@uV`wFOFR$bY{eZACKumx`4prXF4R`yvf zd~WOEJHJ6*g&2ZUPlXV{hcGrwGiUPm4LkkU4S&whGa;hr3(_Z61rqw&i^FP*07{UZd9HVz6Z@H9*6$dxbbe4xW3KWdCU!!t zFu{fwD5rF`X!fsZXDRFlOa1x5%TU+8^~`M&c3mR|AF%k^dcYg`?UC}iiY5{~N#JRC z&3MsoG#&QaEZgyHF2N)VFi>g;_tvkNtn;=SKc!n~8&PGT6|z;$%8lHI>sGVv#WPI^ zyO@~ypXqkBq%L#B9?kyg%t2Cb!>9MZvM8=*4_+j)1%-TDQeYHBU+ffPL%K`)XS0w4 zA-d}jM~LG?1Q?k12(ow1kK;i0vkjf+DbFu$5D$N}^JJcS57ocO(u;!n>qjF_MuU-L z3BYyNR>OM8GBug4j(6lNPMc$R;SRVbNzgjgJJx=Q6Qy@`A5Jx>M)MdY9j=^K@NEbeB1_!0Ge zFX;|61gCxJ`z`(KuD#5~^r)KZ&&N96AddQK=CLEP?z)~8zDh; zI*cK1xnzNmG)b(c`J}iFIVJDFncb&}i+gKsb*=bk{K(UP>nIjhp@Y^+2#)HqKicT! zyd~0fzSA4Oy5(8sUVWS|(@eduv_!kG=DW~YnMxP8)yWBU-#H75KYs5|>1gGqT#6B$ zy@fCkwEXTW{NF~E=UO-6t}3vo_+zI|c1KC+n2B8!u?1t4aL=y=^p#+JuQ`+Fulq{FH)Iyi(sZh>9`I2OI+0J(i+X z#JMdFpy1W%7F4Og?0McoBF21XJ<)4x!D4F^ZSt{1tv_f|(ufzo@fw@wTPhMXap{)X zI-E?Qay_^Q{D01A8+lsvI5i#R8f8MSl?bQb&qOOmGkwtIH+(OCL)G=3PkrhU*Oe+c zwlE(wcwC!6gQ-Bw@V6O+ER~ymia%sb6pz|xq}m|;Nv#UHrq}P@Jwx4!%+irRXX%+~+=9 zuVP|(bS)`_&MUMHY0*M<44aa?6GKx)>hAY}NBNF{16tr0l= z)$OV|V_nfLs;vQi?CVB>y#jooLqAHVLLZxfN-CDiJ((zMKRrO*oZeE7CRAd+daOv) zA3MiU+F&Vf)}8^OAg*%&;@D4Ix}VmhNB4orqD|ZRK%v>?$OFv-TYl77F;$+hx_s&M z4^YDLK0xn3eFdEDwG8Wh6T50OI-i@c&FwrszscXr2`EiSENm|ryHrJ|vo zQg*s^;wP8Dl1o-*^MJJ;AM5IdnoYqjhCH{b3E0?aI&%?X<|o?Zbxk7%EY1h<+SzR0 z`Q`z8u#-1CPHEx%Iy_}U`bxLm#vRdZ&?4{plU>4VIZD$FZ9CdCPTlAI3PF|gOz2lT zp_^ZuS2qPsjL$(N1Kn*!DPf$V6{Z3~2#C5nid%riHVeUNAIbj(c*-YN`+6x1YG9e+hrrSb02v>|FBo#a#V9`bF)OVoU4`Qe9fg7MJFa_W+L4dhl_e9my0Gbo0AWn z&W*Mh;uSNJemXK8%RlJi7l@WCNZcMAh#`K^omO1(hNOk zTLX&PVU(YXQ`Lou#_Qffewo$2kM7TOPxjIvTLI|w3>~nGbvhw;jo0ntR_O_Cvx5}s z!u8p19fJ@|x*<0ni=QZ7U8#(k1lFd>5tS52f*?ZQip}+Nd%*@RGcNIn(`^lFUv@(i zkG&q*WNv7*as|TV{)0l%+w_Ub$|lku;8VzDA3(6!zZ>^yz(xNsUjqX=gRXeL;GtAB zU1gFJKeub?&Wx=$NzX`5JUv``=IBj%ea$1K3v18&VK1A4M;oj`M(UT+j89Qbg!qJK z+ZRN*@Ml%(p-{J*cn}m`tXpY1B8Hg>gw2S4+Uh&N4E>8<(*-|_>AzKwnc2d7Av*<| z&<~o>JVF!DWxB;9!Ptt7J9ZQ*s0!Dw0$(xlW04(^aMw+0`VcV_X%c<+)h!)mxpuqmflM6<56$+^FYa9K3yxbQlYoY3XsBos~WKt@zil$Q>=lmT}d&y5G z=7iMVCV@1pK6}l3kl>g%I||xvOs3}^ea>0b8`i$|IIfEx%QQblfpb#sIRQnhjxE{- z7EN)(Sz_tBn(QKcf~)vi)VKaP2*z|qL`Ij_$wLNvLZHV?(fhq^4(DG_9x$bMMdaB8E+p;d43{j2@> zI+0RZ#_I0V&$Uq4bi1SjXx#Lh{-rN1lU#wq2TaV7@fjZxusDFf${}rOWm!(sxw%*g z{V60&n$C7^d!M|G2Oa7@ck})b@M-o*yg}$vCl@zcj|`U>DM0c0c!2yR&`Q3mc1UWb ze@FWpv6yjtbAmGQy`U1(fJXEkPA)LGPQp%4TFNhNP{vQHKAc3okOzQj-shu%yA=+QLq6hHns&=rW)Y^U1-(PPzd+K{y(tdqDS_vTUfw%3{ zq8TwAmeC$Xq*Q~K>BhEu(4ip2w%3!JKxoBjVUh>2sWX1tu&I$VJ);Iuieq|xr5_+_ zO|df@0Ynj{mgICxBg~oOL~w&0@x6H&O{Y!!+xyGiIW7+kbk6X!Yf-S&{$->(aDE!3 zD4zEZVQpVj;m_4SvBNE#iz6JwhrIomn$6OdJtj?@)@D;LE&5ClQz z+$VN&3RsHz#_X?J#HFcGwvy?(yj;A7Inm+u>|G|}>1pialVr#bC{bOq~dOoOnZZa@vIOBznQcUh3_%i$R-kgJ;5^ol5?d=1M-^taY zL%DPP772p;PWSN*TZ5_`-IR4OlM_$JFm0Cm?C0^WCQ3o!%Z=8fV}RKoJW}z#DIuqm zdqkFf2mRxV!A0ORznVaYV$0yBEvjUf1-*ixj!Syy7N$C&x^bJQnN-K-SN8XmLovxZ z6iX07F;9M~4apw!lEvqDGZW{I+8!EVp<0b*9ZrWv9QYZzcHor0xfC+ILw=(z3Sg5h%9z5Ls>X4o5lS+9NID01o+8*aXZ z7ETYZDV$Z&ea9?v3wyY``is#a>?X0LqBCM{$1&GZa6xgZ?$Z&Xm`<@ukjc zEco^ZgI|kq<3WD!&`4SQo=Y#9JODMS-8(%4S*!q05uX?`pRe2)hp6comtht*9nm_D zoy2RT9ZwPBmI~&^`-5B;`z&J!g?oq4lc0PZL1b0!RB)$ONYutn$I_W%mi=_sppqV9 z2n6bUQ&r@p3D8C)c9A@~i*xH7=K#sA^HQ+d$JSC5}rq*kuG>ooO>(CdK3 z+_Tg>*^5`2@(Q5b?kY+x34SDM!^j<> zCm1Mp&J%2loL!Dxur+}S4EE~G5UCvC4F$imZlvjq!S$)!r_BAqOa3w*wx zKNJ@dXy||x6DLtfQXteDo1FVxSQ}AWdpM?RPjG;8K;^}aquLsA{6B_?k<8m83RcDs zw+6Kd6);UW-CLkj5mSJ|v0u*E*>+&d(b8p2Nk@<|^=I+MoWz@%+-&l72KBPg zxRw)4StEB(gJGp9E`u_~K#A-)nw#%tR{hsAy`tH9V)ZvX&(Y4l(`Os2*|mMaNVfLN z(LTgMSV%uf(FQ~;)dMQ2J-n#;!y&`Pv0o);RW~YpJ1G}pT|#Se1&06Yy}Np6v{NSY z$~la##reB`03nCNNHyxHTtE6PfKq0X>m$%@jO%x3e~r=Ah|bTLOt@ifm0Y~CaM#^V zd0fpZnjQhY1ji}T*e>0P7k)E{^rz9Xm`th0=qOm-RH%TDoljb;A)KS!#y29c;6!cuJ$j)Bylbn-XTCsEYE%M_Ind#WD8mCeGI z7pfjppzYsBmxiJNNxYUF!FKam{t%pLi~r4$K5DNSHnTA_mz1x>nSz_jV?WB-v` zp_eOf>YlNPtXH>#`yoJZ|4wYwv($)IZagHi49`f+LTTg$PA%}07%*?F8DOgm!Y)8_ zpmDEGrWfn&f_2we&VRSCcAFnATu47w$4)@WlIG2*C#M|`o`XRC2tc};OUrsU_M`ah zHXmjdQBItEW~yq^ISF~wee*}*`hM}s37TeBzjxv?vkj^`S)NO;DDG0M&UXs^ z+@o+VXnOwjzKH}ko-P!ShZbZNty?7Te8GF8bu+o`g{0KPb+Eg!ffG4Od~rhKsZJ#|H(z&Y`xbQ)(M{>dm>FN&xh2wL*^o^nv^3Ce?Q*(OH0AGkR*B^u{p3h{npu@>2iShCr#ozYE?+4Y z64rUOIMo5Q{V#gsaYr_Vp>ghyS-4#eV?@qv<|H4F8ys+f{^8L&yY><*YXFilBBggP zy#mJ_vacpHg_#-Afl)a_Q;6aLa2MY?cE@~h1?`jtmCJI>$%I{50@D(9Hq?5s3_b19 zZRj@8G2bV#vFqJC?h010MGUAfTr^s#qG~=#1zDKTS1Ajhs@ICAM7AyTT<~0@=coFt zB8X?G7ksm)6so*H3AtoOEb&6hRMUuET=M!Pf-ZgLY}v?^#|(pEZGoOYN4FN0{SEz= zx*)kTk>%k+^JhjKmRzBS%|gy2UYQ{Hq8nMp>oI0Nix)}~Np=dxJh~`uUV1auvpv@A z-U6!$L^-BbMqxUj&&gwLyG^1AY`^P_ z{TI6+zBSBwrHY5brn!yEw(iJUgEACTs=)12_`&GJrXv~UQNt}Z3@EWJwG6NjI`5bz zvFT#zO&8GI&GhtlPm5D^_I}Qsn=~0^{b3Fei?A0(*WPpwybDIhel$Ew`HyY7fgiT1 zL*C4VhS~DRGM*7FncO>UDmCv$FZWq%hC>(zE(Ieeyb?OT$sfxUI+*7&0SEMX7$Zhx zk>$-=WE&i=^DQCW9>b>CR64G@K7Q1eF3$+QBz!3YnvQh_MLf2Hb>f#lYv+)7;C!%2 zc$0{$F^^#<(NyQ%2`wP?*cr)@(C%5eBFeR=BB{dx|Jb@&$Ox zTeieS*L%%O;4}R&OYnI)0CvpOBm!d~A7G4|37WTkk?H~W88TrBpDwA%Q0S!hqh%zcb(k3kyOF-qQUVxt7I ztPLVoxTqyNqvH|*$g_-zBmLsvH_?uhT2Z!dV3LEH1OIubYo00eAmFZao46?Vu$62= zOsFIes^_alU)QvOc!}TfHO!SXIvSN?Mc``oB&_7MJ}kaR$=zzx-=c(~o%lK3jEfkA zMf9+uHC8#Gd*3~o(s4kNg$B?3yqI^X=dZ63X_nrkR9$qu@xt+q<_@zL)o3rP*epyKnxUcTe=i+{mLBKc04lLLOI$XcS!mf4}I*%wy$g`eQmfq+h-J$|qYg zCW1M*h}LdHfz3|}7ZEmj^zGT+dGx)5%sGO`e?8le4FU6ebrSjG+uCi2FO(EwE+x?C zU8uF<{>+|*N}BUpFSB+p!_S3>wg2(5%yq?0E~%O=Pk)l*G@PrA5&5xcrwm`7FWUc* z9W`#&wJ|;uea9EEZ+~A89ME~U;IfU1Gb@@|4`Vh6si4v9a>sWTPi)h4kW$qCbs~SBOK(z} zROY*{23-7V!jZYhCF9YS1Y#e}aL;P)^4Cti@eq_@aq2crPbo#hf4+~AQ;emeXZkkI zLq5P)~G(u*s4@`OJ&W+#u;3Zi4!|Pk)b1Cn~X3!pZK+U^UBZgJvA=sxNF$ z9{gHvnUpxv?8YBP>7Qw&98?HNEPvrQ$1I2u$#*|b=qx_8Rdd>&@b^UhngPY;$A)ri zf(A6QLwP5L6N!D9dtrsE=dSoDqT-=AbjyFv76XQGp;MZS_%$cc9PKA=>^d^sO8aZB zeoYQze5*wEyJ-U>yB&QBPWvBZDWh@RWzL-neQL=P^`f;c<7WCB;&Y|`u~>hWk^b0d z=XZG{Vc_hlZWG*d;rW?XX{XfeA^p!|TL~fd+qr4pzNB?)jW_&x$Il;1F`OR&AGmv6 z%)|cH^?K;#?W`whW9Y_y!a|d|a{7Em!oo-97uieKne93CjQzfue0;9-UuK#Rz4`VT zquvLfH%OAD`SsJ)U$U#QM>Nuyc-40H-S|G1X#A8Bn~+mCm0wYnjs9!!{_H95b!c@; zY^*hHY@~)~*YQ{Ogv$L@dBfzZD0^oC^vC;3VirQ%1;$6&D%9EJCxv3Cn_F9trr8@sw}*^dXu{E#8E*J5tH5cq z6`i-9&Qqp>_Yepa=a78sV;-21@L7M)MZpGGU^v|e?xGp~#}WKzA8CgF*CqNh^TrsF z-Tf#2dBfj>%z$!K`G4}wV(H%AoBq?*{jnx82LJ6a{4%0&Hk`%(mpA8d{a@ZJ;Y667 z?Ca}+Y=c?_1fGNUcE~oFIFuP)Heg`bdE(5;E6oTXXum3)=e;?ADF}|AHQt1u!dIwka3vgC)L4v~d z#|_eZ63blkt!&pygV^}MJw)Q*3D8L(;2I6>=@a$(uC^-Ix7a&R@Sgr{x&G`G_#yI; zeZzHhC>JP2Pyw1*G>kghxC8!O9VY6^A~(|zyjVu_ajSFt_gQ}a9N)%mSx*a>^T?iG zeGf3j&Tb@aX#zfF@i?f9nYn^AWZRI|^FEq8^bFgV%PoHXrvBz@2r25A?b49KsteF9 zyDFE>2_;8|j{al*e;!-!bN0*`)`aCj>0-frhu4lh-OwtcyzfR;FrVZ6L{Ey>`n^5q zHh>C@T)LoazoTyjlIZuk(Wp&rvhC*o$50~;e~j~P?xmrH$?wBjUUthzw{%LUv%w%A ztnwb@-g0B-f4()NL{U24NUyPHcw)7yZ20|Z*I=gGYWON{=Cb=jWA!k*u=~+MHI@A4 ziK{X@AD*4aN^syw$!aXIVQs0t*@#WJ6f71+j5rAHA1%=jU29L!h?Hscx{uAEJLH!# z3190ngL1qHMDCaz@WiEpYXVTD5SypayV(VyFnTEf!zjQ5x^w3$d@Er&KdHoJiD(#l zG%9b;g`W5E9^h!_L;d%h>i$Q`=?Tj=#0p4JHQURleqUN>FTSb;y^Q^*4Q#380ykmA zQ8s%9yxra>AQ$&ql-x>oFP5M8*>uQxGUvl)Q6yq;Ftg<=7C@=JT>;DjX(eu@RS)dv zmgabz!Id-2BEtrCoEql|!`BeK;0fs1G}H^?0lo9hu04>D>VXO&z6D;xFV4_#wRaKe zYd`ro;60=@%ljbBfA7n^Vd$e^7rXOE^z_px1zGM+&1E~RT#D9_l}NbX9KZXbW?g`0 z{Hyb8UrS7?*>{Mg#|~~i)h?h>_Ezx1z_8iQ57FYBl67y+JRr+daKb0`ceH_#9kC*S z3MOvFHKJe9U zCBb9R;@u(*lh#t;i^hR=sI?)P8$$i*!0glvatjR#I$tf#UjW9V9uFR=$I7>9j1BIa z1aM%!BTyn9X-wuhSvaqn`cyzky=(cyuGOj8EH`;p#O?j@N~u=lYZer;5Tsx5w-@U? z?BB#~E1rHqS@v0Shz%Bx)ReAm9 ztCL=<`PP96TbDqcV{~;1SeXKpAii@WKvjQMJdX4hu75+3y%aZpiED$EdX#)&^2V)8 z>Rg+*8FfBYd*@4tQEa zL_2cxV(BJPk#C#B+W`k2C+=O>Cvp9o^E{kWVKL2>uVKa4rp>Z17?dmlC7w;zRl+je z80Ng!tD3FlOT*H3QB&jeT@=qV8BKQPgxV;DzNmI@M$`)cLVMk;=K+2>gcqNNf_0au zYXckSp-4;Q+das2xpjUY1FAY?>6Rzg;HcHG(I-YzEmGsAA<9f6{tj6zDWsfEt&*>~ z(TqfO0gGeiGUfy+wL7+7oECTR{hh>6bzX^kz<7*pCs$blnYG|O*XfdWkm3Fa3HB61 zglVBW`}k0L*=FI&Hl}&y;JbVFy~S|Jz4uJ0skS89-a1NA$~CU@GWm2-s6+z&Fq;dK zxR&S;jHCp#hF6{RSo_)ll2w}qr>CP<3zB=m)Xon?UaAwMe3861)xYME2A31WRw5l% z0HsU-L4Cl9HOoJW3#m8{%eq=C)qaggDRDsRH`h!LK|2*&5Ki89Ou`ZJdX)}BTzF*V zt?{;%HX*49&@9tNf6Qc6K*797@Z>s}DN1%g=RVBMgS3%b*J%%n2f+}7hO7JvRum06 z6D&{O(nuhn+4yy@K5Lao4=H&_@ez3_FF{g`tswP=CiaYE zNGt1MH=jM{Xn_zd#eTj*2F#Loz z9?TIH=ee$NJ9IdA4s@MPh5CeI^8wAc)bj&ufy*#D6mybjpo@JzqZlAa?CU;l@qk43 z1Y0jw*R4AHok==B&GKsFhk!oYd!ArPcH`DElc6}WRl>#ROIP1Yn}ipVfL>E}oZnA% zuyipW$o+-wt<{N5zQre)>or7Urbe7cDAYX`dtdBG(*e2(@5*&y;t|2jATChA*4A?$ zIT~?82Z3pm=Ap0X`Ff-|-ei-@;eB-7O>f~Gk2xe|X?2BwH@h9Mp`V_NUAbb2II%|1LVcauyp6779|PT; zK*+jBBJZbDOqeXLay=8aTX*V)^w<2x#3*#<7HOM=H#_N}h896md*`h)Tvxyy$%o8F z5+}B@W`p!4q~c_`-SV(NGc@G8>VoJrjpnaYW6Q#tP;(P@)C9t6h_+eJfakZ|c>l)7 zS~Y&ivvb*vnP^TXw4&8&%{rY-Wa~->zml`{I399keN&g3YWEL#-=ONaSPoy$&?h_FxK+hLJ zjesqMz{zVOmF_dmBJHTfeFhV1$b)wY&vANL&auw@9*^{)ha^6WI?IdYRZHh;fZXG8 zKRj=}m%M$O$m*qmaO&WW5?Y3r#=f7ZKzJ16xi)Ln1+nB{9*GR&T}c3t|m0$2>Iblt@BIqKpU zE_N0bvEI{Q4u4D2Q3=4@QccPblu#>7mel2l^E`0ZnI$=aeaqWGt`C|}?P6rBMZq6O z*@C1xpZ@L^A(AKBneL_EC!R8cB?IrzqL&=Di?)s4R{H-3Cs@2dAW`8nu8? zgOtGWRnPaW8>+eR$dy(Y6>#@rP`|IZ>qK|uhs!{8_#QRw1wF>t=bzOmSroui7RUXv zYqfxbhI;zm283om44}2XgUQ;NvQ62-QR>Kakn;t*2IHhHj^KK)T!l1iO#A!+yL=#t z*LSIKiO)V=e6UBU8@S4^p37bW^Mo_j6LWmbzLoeu*G?c!J=u^G52if3cpT(eTDPIw zAkQ#S>;!Tg_Zly^&*EriFo<; z%zKgN$(;D(`&20oF3ibL@BY?Hqr!|@-)Z?sV`+SrLcP4&9JQkBVg{$33yphHf9a=b z*)4~;S*;;(^re^jowhax*e2pOSM$IE6E7Qj>osB#ncQbZzDJ)eU* z&Lnw!dCXctxZ`kG_4mGEgq4=hQrI4t3gn?O^}%+Sd)&*w2Fn|^U64c;+T#g)>B9Nz zAkC!Q7ZXY1d(=2{+9>-1Mc>hI;#FYdia%Qpg=m1y zOGICHfrV6?7)2yO=h+X*c0&qpxgFS34}%9E4W_N=b3^oTvT+nT1%?*yqHs_HgP_W< zx;`@aOnf~{5pT^`p)3|+WFe3&r6khX0I)46UIyWo9*{RW<>(3o{qJ2paEU6X#rMz* z!C5Mtw61`;)z8$BMXAN07pxKvgyI8%|MaZl4taQcRu5zvmw4^53E;QkU%O8BuH$b< zq z$ISak8d(nV!pp6Fk|D?0drv`dun265?_HIIBOf0q74VN^59!8T1--%riUKz@j}qv* zugW|QbLuLJ(uk`Fw@)4By;LJ^x++SH17#^gE<6ZrO(1;_iibc)=PEE6z3QhLUAv&h zs0UK-RbD1hY1>MHywmgvD%gbmA;{<}9Pk$|XwtPfVOJ>{F49KmEHokqL{>Xpacbw$UgR5KljR(D3UXd zT$R9d_aHVI5WO^`$;`@GZ+=W@B z9Ll%`tQkUi&Y%1Alw9Q7AxUw2{{JsQNKg5m=BWf?LgqF9t1S$ zfhfLk8*Trh_U+K3GRRd9dG4xB(k-SM`pH|v)%A39)46GFx5#me$chIza1*BPH3B!F zpX-Soo7w$(aSIS+YAcrhWlO?|-t^?A;30mA7h9{l9+8Mqs5L;EB6yE7U}Q|%8MZb8 z3 z9kkd3J#AWYz0uw+#{UCKQ3VLFBK-woC@qO{y{ZMXn%BfEF2ZTm?b6YQczu5R~b~MM3%+R$3 zV0>hFVIbj z#8u8MHvN`nzYugg8V$gJ9&qULwB%+(7J+w@i}bTac&T;aQq?^Wh;2(t_>t3Mz+^fa z5Zai9A(g4V)n?0;Coeq@CRjJ1HVx)Z$ObhqH2k^0;mZxLWYMguGJw%o&qhLjf~WRj zN!=>eParTdZeQ~kDLidwC}>1`jLT-`$B2CU#ND>^pL_OqLKVR~Nk_z^O>siZ;Cuzf z;>1#XN`!7kni*S+|45Pk$H0F25%7PzrD&V*bRJZEt2#V*onUIx@cAE?^zH^)Rnh-M z@LMV~M}}uaKHCzzj;Sg=AeDbFmuizo($M!ANodWv|A~x8tD*yKTPHGKUyno9XKQ=Y z3|NsLliaWtgO6hPZEX;+=E2nQ21$$flMgT=sk@97GHCzD2KfW(-ucdu5GYJEI=lDu z#y#!KsXPY%%R`5lD|X`IUh5@ETgI>F7-DL#zVQ1Y{;u?&2~p+LchHRJdOPfEdkgGc z=@o4A|1#qZzE82K0<8N{0rsf&+g9fP|5LZt-I$_tyo>5uyRAuwc~Z7srk?PRgYcj0 zP8ySl);TU^{Wb?SNbO#P(_59MBs7cblpbOkV!_DFwlL8C-A)(8qu28i*PlIf8q!yL zQk80JfGhIf7sc=%BYho@*$IJK#4sMkR3^VR(KMda=1<8jVzp@)!N|aJIvxIPHDS&_ z3!&T}jE>J_ucWuC#(d=^+iZjQe~z=k&1TV1yIyL2Dr<<*MINpoVrw05s=_q=KoK=v|$5U*R*MjYr}8M z2@(+>*LWS%X>$vrGv%5q|C7bFx#?EUEGIqlCqt8BbN-6V&MbW5BOcs8DN2$%wxN00 zc6spOZ=(d~C6dUR6hOgugR<>k?7ZdG5IfQLnAlXqhTj-sonn0R@GRrF&)srn;eRrR ziiI`8UD5&nKBi6^E3oP!oOo$}c9hN=?-jbuqRPMDY)qHbcGAYC>o~ts{e>DKkiACN zc;Ak{;AO6^UGyB2UdXnKzIXqbA8mW|XAk1);Nw3-sifji2QT`P$~9zI&i|PT4zB2V z@^Zxa-!VR6cbFY>rqCWV2g|`@nSZi7cuU3FGY)-h$fEvw?*p}5^v3E9xh4Njbpju1 zAs}{~=ft1SV?bXNY*#cG<-~X2nHEF;emCJRW0$n=zq5jkW`r*lIhOvhc z1TFXEX=}GpXL0VY*dBR;XfCek?V-y&mVc&scNjPGktdo?FC&B|Q^xwbf1_{kjSb0| z&!U0ZP8|O+c17RK@z27Wj$=f+q%;4lgQC5d_g&)ZZOWess5EF*OksDIk;}WNMO=*o zrpoVuk*ut}<0g*DeCc2N`w$o&?uZ{9WJiaNM;QEhwCF3GyIHGOG$j8H%Ra%4no%;L zId9ml)>%yXcVuMl{L!=rc`+Z*;eG;tzls>$Jbc;XXrVpP6r%8=yMF^+!~2ZX2K#lq z>LQEM?SBW7I#@wo(HnFNnv5Cid-Lyf*kNqe@%DgheYr0yi{`I2X}G}W>!4{QHxV_~ zNBj4$>797hv;#cw{J-2U{%@b(|NHyk`|GUJIi0iD<@tO(AJ6M+4@@tg-_I_<4g!JpUobj%6$IKx z27#C`tSrF)T+s=(2L565F|zapfjACr{{@4RU-5xJBA^TBbj<@^&7?q+#1SvHIvI5- zzGGbRIWA`}b*3N7l%$Vg`4=DZ*9&o*x3M0}O}{|_9g~!jxhImYYd+Q9gsPwFespB#qSot+tF=>g%S3vCf8CsV6Q9EYI0eMH^CM=Tj*d=I zZITsqfblu>MHg)Zy;*+vw|0n6-8q`U@w+Cby0fO65}#o2;Q#zisktI%<5dyM&tUnR zq!-H6rD@+s^OQTCkhTvHJ}h|02RF%Sgi^LUAckNut~Fn(JDA$e@2~;+Uf~)&G9*@W z@aW3LpDd_qh2HwxY5?ypXrf9>)CzHqa zgT4$~K)IkpBoo0$sbkt1PU49f(IoPs4Xnf{3&evSRFu-2PQ?bu=RlY|4-5@r+4-R> ziR1@WTYpN&`0&7rs5au%haO&>83G=Py3^^df!5kJaZ;odafc1IqCf0K-#g75F6pMZ zgh3-f9IS5->=YhFM{d$4-`w2REz)B7K52iB7f&xL{NclF8AR173D&~zN^ErST~n;icCh z@`Q##Iuq$W#ue}0`9Yw|MQ9x7HU_!)ey`Bi7YkOLE_PS(4$Ci*!jL6w*P#ZV4z1TC zYGTMnJc;iTP`AC49%Y5*AJ@k+@3Ur=2SNV*bn&x94A&4z5lAx?i>0Z!m*a?L>>QD; zkr)CmgY_6D6>)o68vnUmFNr^tw3@Htm>K} z`fILx^ng49FKUwry@ryF!vit$`i&zSONHPt=!q04Uj+2uTL3G@B3Z=Fovf6~ilH^@DPqmEVI zk!ukWq81K3&zv23Mjk(K`(r1)KA^?th68SbxKX5^u^z(rLK%+c+ih4nwtSN2GsT%kOj(L5_(ayv{&oK>B*V~Q zDT6!4(8q|}a6Tp(5t`vn$;4h^$&`2gQq~?`{ux~@Y9TfdeyiZosqpS;hUcx>eyexy z82E%_7cL8oerX&>5&Qb;DF8Erkc;)Z;mVqTlT>~|%3T+&ao3=QKYm>c- z{JK`xkO^L4LnA@}>iO_itLS0W=bU?g^#ah_#v=&cL1H?;InRxMDkaLsb%o6n0#y8DtRrgiOFtl? zCSRWYMR{e$DkB1Q6<0=#nRh=9SuD&1nM|T%4xqy`PU^`pHctOHez_GP%xaw{*|keu zE;%8H-roIp3Vx3H0;@GO{1ffHZ3O3w(u_LxEWQ<;JM<93jmFk$HLnjI3hdk=qYkaX~%^b z+&UBY9>75Pe)uEw%x(N6Y96uF6jmit40};#)99Rzj|)km@(Cv>gJz25PgEP`^<>WE z;D-y>UU>bNia?yDa9gjO1%d>^#mr;!azzPR<2_+`vuK1`|6_CIqLVZwE`{|xE4d;6 z{jv97T@o^wI9PvY@$90=tBPGym`|@42o+xOS09w!h(1*bDpIV8OW}B~&L`>Ygbkh$ zSv|=_BJ0ZxvaMM<1=0WW+J7!8EA*b>Ka|hC(|Mq2>o&9HA2Dsm-_t`>sKtWwT5}z`IZUKp+zh8r z;TI;b#c$EXR}NA|zbzeeDNIbEC&PF7#V}4Ijv*4q)i+X6+{6knwaP=nn&A^5ZpGhf zixu}JmtS}b$TMBIG<`M_)i_LC3-k&a2d9tkzDQUDCCS4sUL@R|G>XjhbKn|Shzb?y zrC$!)hdRU7#ai@bZu7*^t9GD<-8T0_1Y+PY^NK?|x2d&m<*}0*MM|;RM%x+?`qU$~ zCde|g$R6&IZEqU1>8552zfY%1RjpifR-z1ADq>LT=DK01KX=Q(f$4Riu-ydQCBE&h zAIY*FIN<0cXLLQeWt1!IAete?uYQ@?VoOi?%+&GW&uf+5{|8XS9MWl9GfGXDD{U6U zD97HnKBg)Opcxo2RT*p%sxO0)`2K&x!wQXV=Bv&>_WoG&f}KbB3=1mLl8N-kJ(2rS zT5rS=JrNqO>W%;f%;y?|3w4+waTM~+r{X}wF=kYjr~4=~ikTtLygZ5z)RPIl%)iZk zycWB^_XMZlFmu^qhP@YM>rv)9Gi$jiLO`72Mo*|~#B-bQ@qKqWqFr)PLIWhWN0=Il zrpir;)}{?uf9*2G*b$HkOXW>*N)PPm-8=yJSKm#&oG}Rjv+j1TI!|$C4l~|)EB3O9 z_rO%satMiW5S`#EsvL+se1oU5Z*g&y8x01lG3`EQ3J&Zra|HQ7yq*m*s>w!rS$Cm`PT^Xp1J=VpUQZAP<+8elU{^6UmAZ7T=W2q+R$s(5WW?B)`W=%bUK$9RRd3 z$iB=(dN2b;;rF5Tp_V6aT$(S5Ow;_oVm22(Ndbo`oAhJ)qi!c>?6E3&N6#HVAJFmh zi`5i8qD|!F0U{H*{GB0%E$mWfa#KuEu#~fd8$x{ILU2y;QS^Q@oB^}NYmkTa-_eMR z78<5|%ndiJ5ZlY`LE)=L9UyZ%`pMPAxmRd{_n{j9IU`FYOtH;oBh|ZDe6QIx?}uzQ z^BAS0-S1%wRly&Y8>MJm3H_O-SE-2(r&rr>|@dI@-}W=8Z!_LNK>)_Y@Qs z4ux#23~X(ME~|*{z&~zAkvshAqKecrAc7g;s`zX-(dTmMcvF9h?6cPbL_C;!aYdTk zluK!?aD1*i$lN>EeS$Mjj&gluK0>YZN>ESyOhzQ!imSY|55M!E#UFGI8@8*u6-rk; z@c8Vzm9V7YQ$=vG+B z=whnNlQWZi>Z+>QTLU}2pH4YnlJV*9cN^Q|2I+$f#R4}T7-rpW4)G=wxr#cnSajT% z&U-7EMK|8i@@#mv&Qx`Rt#ER3vNf(;hpn`yE+Wh#=hbcFGw;v-dVh#f?lts9n|CK0 zH(!n|xvH=#bsm zM+Nr_ytXmjfdBusKY#v=09(9y@#00cZ?P)yhZ&Xm?TPj%*Z%!^_f&T}5gH8AJwx#F zia;iSn?jK>D#%}2;n6`#3@f(0rdA|YAl;vS&aJ{1)egc{}GDH)l5 z91d4CCf95A3uJQV-Nwkx&$Qp$h`c_wPMxTqQ+v18p4YQL8$SLoIDhyBl=b6iQU#l` zzXyIgn>eYwS1d@rs0D?L9%4bouj>No8x;5SrvBjhXqAxl)kBU8lR&IwE=@k>HBg-8 zZIZDMUB)ESZ67J@eDpU3I#|-FHB>k2S4fO26`UQdy*>ijdAlx6AcD>_H?#lpliQ=w ztxy4z-4yI{VY47pMqs7`yShFVaudXZ(lu)U^K^KfafuZ{{2{XI_C+Udq|vkLOFgoi8sqBR6WOxY={ zI|-o7xD5?60}Hj<)xLNZRBiAmfXoXH0Tw8@Dlurw=q(hobc|Vo%o)JSCpJu;}(^PG2#7kcY6w~5$dX{n~} zPNb!HMGlQ*mDh{)qOMjd+pTTfG+ax~Wd*YpNimU%076qYZd&nx%I7YNG9cTV2tLhQ z67ke$fkLlAQJHINYqx)k7mDI6Nz(XLGWK zKx(q`7acTh(kFqZT+AOB#5&C^xUN7*T2ergl^Ju@FDpd*Ty`SVUQp@m*}CR#bpf24Nn?`hj~Sp{w)(gUzkAL zyZ5eklW{Xmk^&Si48hcoS}R4j0h4XkhiA_2-^n>fojQlv+s(sd21U<1#fsxPAA?wG zOjHI69vYKsSS+O*2e`=PhtN(gM(T|F^i@sA=8;Se|M%eIZpdiIIOCr{IC+=YN@dP6#vWvzy{s$0Jj@ELXN+Xd&_ASNM zw_OF;?^s@QobbW2kX;)4IjOvS`(r)kKFLq*nv{EB8^Lh+@gw3H&LRtFi7?troU)+y zHd%psc)9Q5T78$7R(XjB-wO#C$7D>(MsFnGBaskWaiTRo$wuBBBlE4Wj6xdkf&f;s^_u;P_U zsq7m~oolfQnCH+`%r#3c@(DKb65!7D1iIcCs!Qb&1bpie2ah&spp=S*mqae=ySTUv zagkFOp5>GZp=)W(a;|4LqzX31{%+Chb_Y3JUN;Rs6~vwVG*#P)c!r4Z%`npH?76eT zB*RauD{-9R16#~B60g$q2S0}el+13F_C5BD)L{MGhMBS(`FfoAg^~B}-5csfJ_&4d7-T0qVyFp7+ZR%lDmsBU^XE@Z z)x8~RT4>WbYk3H_(Db1g!)9^5F>6(MJQ<`%Zcx(--R%_?-XOI4?5?qav{EXGK9*17s zK1+{+1sUR$*GbA^xkhq3$m4uVzZMf|7K#$(a+~vK+)w!)8HiE^<;kUgOHNL9m!<^$ z&_6n85#YDAHdS%h_Cf06tEt?L$bW$?GRHZ?es>m8!tIg9ao+&U_?$brtrn7u13COPYs?WOUXVUyD%@T>PkJFrCcx z`&B;YcHTTmaA74^DZkMyO?<1%+v=yZ^m4!al2T>dI@8&L4<9}xLP*D-XcXtui6(Nj zr4#eUcYb}~CGNV_O-}QUD^?t*S=|uDha9@UEvg<2_%!9N@DfZt!bIwT%EuSfcIJmq8w3f+4CSc1O(df)YrDm_`4 zdgtVMTFLRD`%ruSz7DRiNMQ^L5Zxo&rDMTs6VEGz(Ia!AtJikzH_G?J*SC})uqzr$Jr?L`P;ai$UTQft8Ad_;Ylnn3wseeoQdQJralJt5Xj9<=BQ;d(fXEpVG}KN30nqOJ{e>5)X!is zSud|nN(yPyyWl?vv5UPlu8WG;4}(=4MvqL$`n#R1IXg`%nc+cNcRvM9&y;jp?8X;g zRKs(#Nn3F)vz6*Is5(yHH2*2tCBS8k{_N3Vu}{xzqL)SKTW(oJ$)YkV?5O z2lkvj{q!|Ws%ODyg^2{zxLlYLuSWR8g)9VmQmJEIRw|dsKoEXjWjhSopylPHCZDAQ zZ48Z#76B)7fG_g-!FIHs!T@5q@A*sQS#w-@)1S{hv8A6U$P>O!&HW=K18hJEOj1NN z5p(*0F%Q+T$%?HkvNUJezX_#8!`*CF{Ust3Z^cHQ4eG1T<|?#ZYef!v6jTD0zC_O3 z+CDUF)sr39&~p@Fx68IMFdNm2O`MXee5i7?W9&wU74&%ikrE#CsVcfO6NxKA27oX+ z6H|W+rk7`-{F7S95G~%X!TKrPf{7%dG0v9PK;*5VF|Pm))cPafbB=EQIR9z7XXW4y z!-?WFV(zrHf*y)Q7JnK`f=-=chc618Em#(;e)be(VxAd7UIc$4P34E-`CWNEvlU=> z&z0k#YpJ-hn`3of82Gt+e>bX+*ct@Q1&?_E4ySkX+`kCp7J#U;6&{Q{ado1U)-p^q zQ#%)W{NvP(|EVXBn=5S>*9@?|DN-Z_7%^-DgmJW6SLVMr+vi!1wRVcV}L7 z7;exy;)-7HLyd4)-A(QlQx}W4Q}8+vrG>0|VGY!*gnPTXObMXr3|NTk*Lk{uT+q|n zg;wd{Bj^XVTMN&J>gu%o>~>(l5vcy(eQ}536PQoCAecyci!u3za~^3ct^opumB%g; z6am(gU*<1eOXa+iHcxrv9gaE#|NY2wKVbdNXtW3d>jzNT3HHLv>I~(Lq9-AwoN>gP zp|PzMdfl;qGrML*2*jIvEfl5~B@>1`csN1BO<2fxJfU1p%Qa9;5KQG72#Ey|tHGb5 zpsUnOsQooH6*}%?a}%Kb!+93Q0=A67GU;D`h>v8ejKph#hK5GB)8MMY9Uv=i-iGt* z1t|o!OldOBd7386t1(%-Zd|JP1xnE3w06$|#!Vx@yPIFo>lIq--KWp_@ zV?RU+FGfIC1BM|_p8CPVTp~(`0gvEVZeB7^CzW&*_gVYK7;n&ieLPw?E57sSN+Rlg zK)oaI(V*&;2BN51Ni?C79(&7eaBfAHjobvp6TIZMpkjwna~gbu`>?=aN36=3GcP15 zRns9JY6eJ;Mw(I4pKfntA3|sf2DuOKpP^`pz9?Gpt`>@Cea9z;FF$&X9D$TfI}1 zpn*@e7I5Q2#!lgr2YEE4}aV&%K(M~{%00| z)A0#z>tV`tX=8+p(fv$=D^}3+tninqg$bhfpp|wN5c`(?`Z%YGJCxdU_zFmTlsz(^!evQN_?Z0d8)v$-M@BZ8lZWfKq-H6%|*GY38woy5d zk8f#^X47-lJblw_nnr;3Ub5^?J*hne6{iSvbMY;ZB(1yQKWu&M2dyar%il)b79;@S zwAY{g8g(3~nz*F+9T`u6P96A<0yrr;J#^x!Fl3%ytgymgW&B51XZ~JfOUKBl!aYE> zeOyNtWZ8;XG=EnrJi}WwfMIu4E8~HpUv_wScm$Yw>So}lDlk>rZq2w1H0^dJIJwGy zCq+1IR6iQis_w04W324XEZ1T@?sPsZ*omb^R9!?X?RV9sYGC z!^r`&l~aR@9qOI7ce)K;E|FX`KV80Zg%}+1FGeXYEUv6Jbe8g1)zT4##XyOA zU&b>i=l_=TaO4J}8%FpdBBX2x?<+x9Yx4G=&Rmxw>CSTcte&>!Uw!kzs|liAHDKIa z5LONq3IyGL4%ED-Sy0o{)4;ueEG*;{GZJZiE4=n|%Iur1${kKQtQnM#|Jgu9AeS9A zx=OFZ#t|DlsIM7v_+h85-op%hXe0{1-uI4wf%3?fVI1Z8T%$R%vL_iS_x|j7*dcco z)XmVvm)F_JkI&L2mpdQ*D-scNmU2Fa)!?p%1fB$q(=JWzV^)ilC$Xh2t!d!d$78_3im~kck!Oa|H5c$n^D3z7?g~ay$5p z`#Lno^&hE7Po^b41eyxom(1<_WGPngWfyGlQ6AJ*r1Wce>A{uiN^4)-Lkqnjr--F{ zqCXQ(NJx0Fpaca4SH4`klFv^5C!7GXJ5eCO0NjGfrtgkug7qm*7Z5&=ZT?$YbAU)5 z)AbWI^Z;gRYwVVg3=p`Qi2T#Lg{M!#4=>L_Cqzyy`F;S@VDcvb0CN zY#Pq9uH%mpFST*}2nh(zt*@_722+6&w1pDo>|D*_K`5#)u-)T}_RgF;mM_X`?8M0Y z+i?z!6g0?Mxh-^$G&v0q2Hdle>mf0tRS}$pD>OeQG z*q*4*z6Cx479MW+0_2%vZk3JG7V0@WaFqzMNijp&v#T$llm8{2FrLOBggi zjJd*N%$kBgecr|sU!I(f!FH3%-abR>{dO&r$V7Tx^Id#}KrC<QIkI7$a=)i1F#ezt6l$=)xrN!_pB~flBO1 zvD2q)kcX4g2d!`Xow@8qK!a&jnX|BfDtN~k^?xof=o5P&%79|QE z^XC2IR>8I6I~oL3c7wBlaRh*7-Hx^uIBVu{B`*PCFyZ_CvtDVJxB>1au&}TYFefyA z)9?%+Ga0@FrkdET_uMu@$WhjT3ShyO<<7kT7er|bFdd1@qSlLU-zT{esj2-p_yo{7 zwFfkggvJDR8B2;460o%TP?Xj}6eA6#yXjC1+tCPyxhuGUp}WBpphpXc7= z+99lrFywLX)v8T+n7(Chom8ODZ02J5Bu*mm^Fq`pXf+)lS(BT4Z%+O-{CC$QvgwdZ zd?3)3?|-%*Psz%MU|7Xe8Re zUlqDmG^cQSclHXA0GDm=+KQJV-4_gi-^Qv;w+t)9y8&xU$3#baCO=yKyEXQ=1Ss#e z`iWABcANC%{IKmPySMN04t5Ho6E7e?G}2Zk>pwi?cw9PV+p^JV9NSQ%m;f><;Ee%2 zT0?@vr5o3^A#K>}pRCiZ=EY=`UnH(G)sUKif>f34`?Emq8S>}b(R(&g%K$}=ZkMZH zGLhmhpS=(=vNIIupkM_JL$M-aW(3mDK>*Vy-Z`I$L1&;IE$#0FGMS`>5;XXK zXiegHN2pOyt(R>;>@^yJ+D5OZC&~J0nZrk}U?3b`s}g1(Tgq1RBD_Dl_4`|IU-XVU zO>@e0olTM?_4}wR3&70pEVkw*ed-jFnY3dju)zrU@0%_f^O@I^{nKtzo@`XKq<-Oz zeIW1Q)>Vb*+6uBm+WW11IusQn&Kq0O^do<+p&y=>^a(Rm{0j6fi;} zHNv!OhP48!hej@k*zA;3t4#S$2b%5T&J=JHCDUqYb%{u-s<2YcH9eEW9Qt5=PXS6i10r@9T zQhVTRz08x3Uwefw%iW|sshX>QCIK1Axh>x{5=riIG^BIr{G0rPAZHwaFaKH0q0ZP0!{K?&-Sy}`gAGPnB~d9;@G9}&kw()fRPUy~mPKieTnw1_`Y3D#UIz^iMX zw#&>^!0@UY1PP}ygy%xBDmvH%SWDpSYC5}z22^W<`$+OdqunzoBImciZX;6k_5N{2 zC30cQwSjCYlSOMEEqu1*YsHE=MutPeL+pDA`+c!+>5%_Q+v_jX&3AFBC=&^s} z1b{`-aJkIh!(|`50_MqcB`a^w*bnC8Lu7rPp~EN&f>!XKm$!>`o=3qJS}NIpmELGP zk#^kT`{8}ahX#(?B~xBbBfjExzF@5U8#kWzDCm@l^3Mh!*O_rG>rYW_I3*eh%?*5e z^~<}XFAh{Bnsy>v;u9}@%il9+!Q>)BIF|g2Hm=2yyh?jzP||9lF%QXF)M;q)-iL|@ zBujk;g^WyW=4j4mzJ!cOXu1w4j{nu=CPGDjuDWq3EAl5i%M0S2L!_P;3O1flx zV6>&9^PPYgFl2PPROM@ZXFQO){K%fv{5248axcu~O>fL1K6lx-^Qq6&S022CG+%U$ zRFJHNO6#Yj-Q!vMBl@fjANSHA%O+gqh>!Gm4N-A1!|8LtUVG8uk0L}F4$ERVy>AMg zy%_A%k-2E#lfa;P=64OKHk@gY-b6R@UJCL_qx)7L?_d_X5fel!`E_{@>TyaU)%^-@ zYeV}*>PNX?gDeKXRE$kn%!}vyVok24cpMcH1+JxXHx7nxiexHiNcIJ%z_bJlfoNqX z^0-AHW_(Jr)tQ0wI&&qCra|3!kjd!1jxxooxP*{XPwo_ikae(GM_qrv;fJxr@D8Kb zDnW?bfUGt6Ufrw#il;l=C`Bio(@3RLl~9;$VF%ox;G6?bulnFPFkyo4-RjtfdK89S z$3;95Sftg7i(37-%M}RRY_C1z6uI{^onLMwdcnJZ9R>&4Vhym z8^O&swLfGpOYj+O7y4X)Q5xNAlsYUd6XP%F#E1lBa5O->`%nv8kIe0u^J*O!P}Jr= z)Vgj&Ve$fP>XIELKg=vj=rps#^Fi0+uf%G4VDfj7E%+m9{CBkAK$e^Rcd-Gohp_iGQJC`aevt6}eO8w9 zA^_KaV91&t*J1C&*B;8RfB_ZmrN&1xt_}D!&4ZckK|lnl>_Ot6r?}YcT?vSJnvAXw z6QD3go%;wvlmAM@%;&Rwbrx2h$A=9!(nDRJ@+4Rbrmci{orWS%%&@yuAgSM_ZV^r+ zgH8)VA)STo;F0zKpVUm%P8C=K&zBGwl|7#sr8EeekqqY1V}=pPCp71eEv0wm0-d&9 z<{3+u=4ZJqVy0a)IIBB^KCEmkczjAq8$R>G7?_K2*CxH538Xc?%HGmZgG=&z9I@8P z5k5@cy9$V9-A2b3J2K}yMTSJ@y^*btFcQMH4aVAx_f%wNQU(N=rLfphYE}pJ`wiQw!lzAx- zaH-031oB;0_F%a^L=mkd|HG=sQB9o?L}(=Dr$i7Y8&op4r}Z;>Ws09iS6evKN` zpsF_r)nt{_>k8WnDHNJ-+lGoB=>SY)b}tPpw&^^e6Y1#`w~lyfJy`9Wt-6lxR>grH ztslDb2jcGXscH!Ugct3Rpj`QM4?+z2`EJ#-HV&yp?i2Jrfl7l;<aukwnPhhwSPcFn z%xG2>^skI|FR?BuQXua^cVyM_URvUJNbh90o?q^rM5Et%^etxj`BXsd*;+3PiZbx< zumc(HgYgy(Zm=5Gz|o|iReM~SVuOx3Liw`O6$YBJ|KjSnhC$wTHfHNG3gTlro ztzmbQdX<0RU?~P0SJhe~Li);0^y!5G~y?lU}X1kjLS7-`${ z1m2T*n=bL*qT#Bnv;AH`MS%&0?vcpr8m_|6T8Y4PuPuz};P(nB5&sgPT7a0r=itg2 zf0bmKakE*&=KuBmFfiNs@=B_51RiN#!sqY^{wnQ0M~|uot5NJ2ym`4=IXDEXvdxKl z-wm|d+y&T6**!WA-K*Z~|DxqZPTdYW{!$>6O(>EN^q82R(`%7;-UG4)h@h;*qBosPEYGU9uS~YRnQ_>Mb9>!7>3k_BSQ;Y`c ze=EN`k@BzloA;ak8v zF@5+e!S3jnCfUMK=`(?3moGrSUS_jP^ht8hJO9M%jBFsc5EP}RL$@%td)#`el1NDc z-*9M1Z)*fcOf)o(JBDz2Q$&(DNS&&0RBbJUHm*>00~P=}Si7QO{@l7_ zlqx_hDSR8xfD7f@tL5YAqNa(6QLM;&_QTKi!<;o)E!n+KAfteG+xk2GJE%QNz?F0W zltV-LpJ~zR0~Nfn8r6FANFB>w_fl|u6cjcj`3`+bIaoo{Nyns;=a%{|KGWcld8m8;-JA(>5zXyL(?h^4u_36(bJD zCsh$R$MSe@RWNNe!_O3>WxXN-(j8bqe?GDA5M0CO^`9X5Z}kO%A+u*$Prgr9qh1W^ z${skg2lxS2A!Ya!Xkl=_-R)F9SZO#_cX?i7U#i+I725wu^k8Z9^w{-F3KaMEYw7=G zI04Oo)%9u5m@M~3ou4vL|D!Xoimp0hm(dQ=8(2vHe&3w2F=K>Apg439dyOWbY5TiS zq~edN!~3gOXf>oD?$C74V6s&q52g(t>GkX;EPHvbWFp-~ip=eym1MbB7pV&J<1C3& zfkpw!r6D;l&twH^WzKu511hx+OJ^*jreWj|cBfAK0az#(R}f7<2SR!vLLl#94viZ? z$E)yOm)&BnpHIZRvF2|!UBULG)Fqm|;KUH#k~iCZ)R&{+n8F(=Ql-d$i{L%wO>lEN zFhcYXCIxQUCzs1fZop?+u1~PFW&+!0h|4vKAN^r_=(AR0+FD3Hv z%oPs95zujHYaKL8Y^FVEo*c8l&~1r-ajDVVp8wq*-$i4Cd~2(d(*7<7yk^umeKeD~ zL3+7MLTta-_+$Iobuia@@ba}ZAhS9IE;}ge76G6{pc%X z%^?1saey=SxZnh=0?O~urxDOa zWi7OL1!aa6e9XN51kj^Q6ZHD{tziI-VNlw$d!Ps z&U3C-(_cI*6kzb;1MqXcFYoeeY0;&U^ycq0L$u@fisu>&yEkQ{KuC0iK&K zSa7dLB)J7y`FQky!^ufrgc+V~nRx?+4Y0zFvAkjTIQQ4ZL0;+WWQ+08ypt$Cf z7h-pmD_!r_C}SQqPw8CWyO<=T_|aH7%Jlnm*GdXdr!yQM;Ie}DRCw^yaPtURC3u)@i1+1Ty{5vaaS~oHmiHtQK-A4%VB^;QEwN$wGOW~FzgzyU*A>&Z z@Wa)bbLTfifxhA^oC0ii4!;c`Ymw7*-1EI_aDyNRxful4m_^Yymi`R$68P^!2vSQB z-*7>vVeTN6p*j%y4~pLFKexOxsTQ-Z%lP!P-(LRJ5#d}yn)A6K9rCLQWUrBA=rcXD zbnM>fdBU=%d;WNK59gsHK+;FZejk>HBwO06NYg`*dfX(XD>t|Q3FXYa#qr8q z$IVWnkzeZyN2+=8rp+FTl1G089;4Yvqk8~SKn9jw@`&<_q1KPgDs7+YE(~MglS9C9 zBA=(<<-9YuDE7mq*;U%P8^6&uwnyk7h!cxrXz$8HkgKLHb89gaA!)|ZclSe8Y2*IG z1<>0zLi4T_?F)@-&w!Yi6?PZ?LyOi>N(!r8Y)ZZm@pc-&<1Lnm1m|JJs>zcMGw$)= zxo+Bu8;mN1h`pe~H=YnmiH9;)veu;zB2eo%h`Y6c^7nc_#b+6WvP_Pg7~~$2|L_4R zTbLz0`@n6YY+e*^SCi#4(*D9~i6&Y{qmm;5RD5Z{XVNe|c#k{r?B1qjD~)Om_@Ioo zQYh|X8qqy@HNd$)$sd7C_^*WpN8>mGvX$UBTB@do@f(I8Ab%o=I{fqKkfwH8=7O>I zaLc1aO;+z|i|4=B(U0dT&n+5skq0KfJ&xIg|Ngu;colX;f8h%@HRvyC54WNx~!LMc?I)Da9M07rO>tTOTlH6 z6T5vYj!QuV!GB#EvoPcnH}7)nTQ4fa+o;O?`KbUh{M&uqyoikTe-3J)*?+4fBSJG! z{(OL`9Qnl(?d(r~o-4_Htu@c}2Vd@Sw&{4^*O|sKt&yYqk>aIE;~?oCGL*;ZX{5R| z=Hj`4E(Tq?^078YQ23kYdzc8yC;2vVD0f|I3shsK zpl&?KIbPtGHqm)Cyf6$I(8a+*)nvV?)C&)vPdCGU)1P?S_TB1-y^o3uiT{>vNz0o( z@#ERkHMIl!^AR5UapOP8ed`xxf5px}q!Ezg6NZUWk`v=ez`H|9X~>9*i#Cr(Ax7ww9lW#70`N8yc0=1F+r?Rn3xB;yQ%bZ8^j`JW~G`Z%en*DxCMPl51$KPLt zxtcn_j0<8qBP(x>a27Z#sl2IuvG-W=w7cER*MMdd@JkZW!6_Hb{UuK>7~aix;)Vsa z=wuTLrHEu!Q=s_Bl1UI_pmS&udH%22J&r{Yh{k(psk8-X{q>B}8;kx_wy%z~YjmB? z$A|f|Cm=V9Q710|oUMb83zVO%Usmj|Z--6VT))wc@9YISrMnthz%q9puGAaqQf(b( z!h+i`B7&E4TfJcUKwn*xi~PN6IIeg4sg#VK*qDB4?gwuQemd)rSA}@R13gS+soLHG zry%E&gwSYewt#dAtj)&sd!t2zbb~aZu*XJwn~szvEu&Pj{+479)73_9M5)Ya>7y9; z%l0HPT`Z8sQ*CwbM{Yd8RFAA&eB4OVGYEfK>RLPv%<>v8BhsLKdY|aN2+@5f187PR zvx%!mpjDk!N6u{z-t4~K0kX`U^bm5YBW1(7V@=2>KOqbmhOFf*%$yGF$9tqRfcY7W zm^q-m;z~0ubNQ@F+Y=g=zH@tzbZq;ryDP{q~5W{T?a4q+!*V`B#MVkAVOBXLPVnE$3VLe4t1kPy9dh){Nz}*6zxp6RmntpU-d{CeX^V(4jnTrhwk6{Q~y#5iKJV$}BU*8KY;28ykei@cE)61_LjV2dS7 zM|mwAJKR-X1pJHIMJPOG7H$yrEDJXafmA#1c#tu7mAvfv5R@T{X9>EA`EZ=ijg#R@Qa<{i)3MLak;tDz%)PvA8s z@ZUWJZ|F|2@r1Ki0=WwB4+N6U4A?~3;f~?B1F!;qM`;ZT_rIgOSR4t#-X7Sc#n%_{ zQcxwy>`Dv=EEkxfJo&`RpS^sYP|WVphIs25d59I3jIdWYJrcB+R-ZBO!I}ZIf~@_0 zp=v4h^TyN~Lu^)uDZFf!>1TL!#dvmdxHvwKEfxTUDE003`8yzOlpVjJ(0p(^7J#H8 z?0S1Fc*|dK=Kj#D2mC_B!cSe7O5xLjyiR5aU?s5$77bdk0>N*UhSjt2 z(4#ws%|V=E1&6IxXc_AHcRgbsQm+yC((@UIfWo;4e~NHlVs1kZ%-QrT%uw^KcXW<` zk7!z0NTW@N9861QXEW63J>_j=<50X&Lq^uaBYF4FGm;Ln_MFY_G)g5FPHI%02$CX@ zS)Udk%)B74^zFU?W4b8-v;WHbn&jJHKmXCscv#H8^9CT6WZ(xnCXKxuYkJ;%uWt-m z+5#rlzr1L!wpc`kAo31uo2-lJ0=Ea?w3`Al$Ip6EzFsTxn47MLp5NK)elQ3H%Gfk- zq@e6+0aLERNzHkti9USpdTXQ(vi82d)OA*~c@b&OI~4}9f_*dQ@##0;c+Ab=cDG#m zSL%aA6T@y@)6|*^XO}}N+O|g&&(%M?5ep;)Bl?9HdEC4RK)G!}^i^7w0(;yUbk@FC z7ya{Nx*&&kR(Ethuhe^iS!4wZP8GlVXgj+=D*=jf+z7jNpRtV%zmxVL^@9iDPAA_B zbpDK8sXPq#%K?^9+Pj1b3|>>sbE8FMxd@K1a|(IP$KD9BPo)zddOQQ7S~QC|%tg#c zxUGK9o0*qdc5vaJWv=a7#(NOz;nwIjiZJq%26Uh+0#4jI(@Fd;pauMf*Z0)t-UVC@ zkTkxexpnX0(6H7lRSo)O!3=2Au6por8H^ftw`ruQKSLH##Atu;q}dLpYRy5MZw`^0 z#F>}Ml&*C}&!<1q zHrQSUW}wZOpmKum$7R;%Pr1EE8R=)ZyOz}k>p_+3USV*)U2oLsit_vc8)(fI{8oqR z)INjpUQdI7^vz0BEzPLkL!;j=aVX}1VfWd>pl*7}Y=AX<#?e2%kR^|;shYsr^mgJ# zb&i2A6H5y&YY)^tUf}2R4w?o9a3hI@PuTYTPELp%Q2@}~t#~BU&jlTL)4B7~o$luy z6$gUQ0y~W&w?*e3mvkYW+4B1JBtdf@gmvJ4(9@%EQZ>lW8ovD ze@^068t|8)D&P1k%h!WzzPY&gA77%J+u6J}{Q!)?oXrf%JqvnqQ~rFe>4B|$+EH+_ z#Q5~xNLBIXnD3%50au?b!yF^7X3`o!dis!(kF0C+FFo51IkaO?hoZAh+*|Q0khg`6 zWPhOEC=gKb314h#RU@)q`C$*r~Obe6b?VIPMc>IwJRGb8~%O++K{3g2=3mvBHAdDWMgRNziJ= z3d<$Aw<|IXG}E|locn8js|=u5wq+LRhu&= z6s>&W3zGYLbX-@CALVO(85oVI-LOyd__Qz~TJu!QQ9nS0bXgK9dpW4-`zwyuY~+jNc3~6I=)BLf}(KCZkbyd8Pl>HGKgy1V+RLL&5G?3Jv_<{&G37ulOoD8jLK6vyGn-juTU%-(xNIJVz)KHvMk zzxVh(dh}O4&h@_5Ydl}C=kp3Kv`NNDH1B6SlFSDYPT>Bpe1Hi5bc)Pp!qJPF!)}$O zd4YaWD)lvfM24Q(4b$}p!472qTLC2B)U<@fcYrLgln;len0E&a6}Z3gnu;2lAjR0e z()@pa-^zxOwRs_Xr9o{Or`BbcH92x{R5NYg z65O$raThfFQ<5G-#8d26>^6xDgOL7vKTMlx@K2}vUvJOdyNUhU4}Y>glN`|5vr9U# zfguf64XUtOa3B6ld<3)`J*_^HT`{>~YFqa1PqQIDzQlFZ^^yZo8R2k-{Qns((wY-H zRn?QixDw@VP{CgqPMP3ZWSOGq{-TH?iFo|@VtRrI{#W+wbUDHRlgo^G9Qdo^*M*Qe zSjV34EX{+~IODfH|CgGPY1ExuKoE-bfnsoIm3o`sDdJ8OmQ=gfxbyx?rZA{j@V=nn zOAO#Xhlhokl8$24q5ytuI{~EFs$s7ggM*ex4sO|hk+j9mc4B#=;y-3v+u96h(hgTg zRZaS$fFjlOyG?TE^&fm^tny6Oqbs{`0$z{o_tbL5wmX|a5AHt>%=0G$-2V)(xu)@5 z-&JwP^WSCGYKCa9F2k9@QL*Qb=HFJ1oqcfjH6OCS+=~t<$Hm3nkh3NcXKqD3%BQaXTu0VTg)ep?;`MRx}6!xS~oAC$wA;Mko2u^U}$x10rZ9O8pZn%~j*28u}^*SEcKTC)l26N7ACp zO_M7F5qR}UkMqpFy~(TZcsl5+($bur%y*D3G=y8MS9JBZA;(Sc-j-+1-b2Vu8Jri} zo%exJ2c33fN8j0C6Wek(dEcJ;-j!Gzm%(uU(v<^u^j{aJ6gq)zQbiJ69UdMg7;ln! zRLi%>%!~GUJ@48){|@snS+7{SviG5R4=F5zj$)~mKEoP{Lc=YLm#@yYtfeO#k1Eg= zvllxan}YXvi|C(DZCQzwF`o8^cS85hW-wB90ayNR&#{gHstef4-sA^wxo~*=8gDQx zz04Aa{^xFvL$tG$Zy?PtR%v;Zpun;QMtkd=$_G zY#V%9T6v<8yZ*?g-23?(+x@z2$cn=w4fst{Q)w4H&i-ZV zhZdO5kr5rY=O6|Ol)?pFc@%%qHq66TU^1^rqPVoNb~w|+!gUVF!cc53#iiEovp%xk5L zJv!SeD?}Ot?ViF3B6Q>FhBlhJ1uZU+zR{F z-2UuWuLgs$E+9ZNX&=?}B@N@`HMsS+<94;8^y$FSx>|s@K2}7dVRCxM3K-$BQG4P# zW%x{)b#w!`1lCxlT0&pq8n$n_Vc>()aK*ID@~Prz~=0qb*xew?*cAyf@Hy= zB-q!%Yuh0tuQ7puL;hXhz7k%-sVI;K72A<@f4aT93y$cvv&e<<)g`7$dc^*GNcv*v z%kC90-Y+h9`vNZiid=XUw5w3YNbJ2=LwV1|H1l>~7<~VHUpCzavMG6v?&p7{uUt>Q zt1`UvzGK?al1`Er&4`_H7w%RZzI0K>)$v~aswDpqG=amvx9RF)_p4Yq#qi^RD%aKL zK0pp&%;D3;U}B^8-@~OQJ%+2}=qvc&O;(bagx{Tuz;f6bW*Uv2VJ&N_@!w8v^wWa| zz^z+`%waX6Mrs$@u>Ulv%2)G~;Z48nokdx98HD}(Skt9j3+8f>@yZ6@XHffn0L$tw(I@R z1z3d4M2~Dok%v)l0C_JS-2voc_}yl;ipM;F8k5eI%nfPU1%{*Z!Xk#PVVct4q3W5g zZwYEZzVKhJWE^MP2yDt1lZ^o2G7>|ISZ4v_Q@ywvDbf3AF=~Hy8r;=lZ_{efl^*A5 zwClI)BjSg?=GZgJrlU$@^yZV}a?G5(yVaIXAlv*%q46OS>2|(!PnuKj;qV#Im1u2j z#m$wzSXbl4ga6pT@?dN0%K_<8>i9cMx4}tV=K;mfR#<_t-I1SWHixYIg!~V|`ETj3 zUV3^~``&p-+_TUYa4{Bu2+7aR&i<0B^Rwk65H_geMe7{^Z{A=hshK?5YtQ~kyHR0dg9{ZhL}yZch!G> z5IfejVPy(5@jh$g`7Lvs*lspRV`}<@Nc$I3W!nerl2~>R0hiNj$R1F(X6;VW@(OD0 zbhqP|JTEp)X59l1KYG-E&ch^hO4@QiJsV$URQbnu9b`~Ub@btTr60=%QWfLBXwJE_ z|CR^1sNNe4`GOz}`X$sZWbx5K$(d8Qeh_;Rd>Zfwf#L!Zb1~lMZP~svo12A(L9C7rdqhGtGqJ^nTs&+C?-&;_s>b`VwJlqDDNp563>+;q2Y#O0$e^*kYz~IT!%e1WU%OyIiWf8EDSG)2v2VF__xc;FOMlHXq?AP z7o-#^GIYo4I!T_5_Z6Qo@raYMpKO(GzNoL2Wr(@elWix|9099LlxINYd9$zAur#aa z)r>i41s{u|NL&n(?c;@;Yk%=NX&lZ_kmUNA5YlkL=)#QoE#iW<_j+zE9Rr$GjOXW2 z1L!|NT7tD(hqr~3aqMmrFrwpN|X)8y6G@F_Ek@N`_X;%ot?(D%W=ZzClpB zb}L)DHJkkIV%zJsJBeb=5oCm6POhnw4=?-)V*#@Zr>03fH7) zet@PgNm@6mnDk{SACWGDIy(hd`N6FnokBc5<2#2dB26{(o1O9=^>@?_-fj3@JjmFK z+C<{y$XC8m`+JhN!0O-5_b#2J5S4JO6d&X6M%ai!1bQ^ zJ7^ckc8X>AuKT=Qeb`c&H^J6Z?72UV6>xJT3i^k>Cnz{LYK_>avf518KziQFK`ka! z)mtJl{y-ctf$LcO)tt=8m};n13dZ;6T?UOqdYJ#85W@x50*ePh$6JL@Ff9fKFJ7SN z&ofv(fm*$CVA4TDo?Y>%!;dEjbC!9f3Af3D8H$cC*Y{z971)Iu**#Z@|Ic24UD@h5 z0$V(|{LTeHZ}imJB|)#VRFIfNzaKJ^S(hId6@2D82rmo#(|o-CJ%?Cdyer_yDM~Z+ zCfX*ZsPC4aTD{P+&+M6T4?6CIbuZ%c6SSc{<_A`BXuYKu$UGMA;}(?r=3Sf*zSJIf zihc9@^&mvG9wlUM|EqTDX(xeSsy zj%F03;eA$eYn@ZgE27Aa+%%Na>(R^~ra3|*K!UY%AZ-tTjV`Sw;qY?=>dJk9*yj+` zakEGy*$;$x(cJb(xN?}e4`c@VoKKgHt%h^G{-CQ`<^VN%7fC>H0^lWt%3$e`L*lpR z98zcn23_$RrX7K+$9r8Sm!;VRA07wl)UomPIuCNi9gD_qFnKi?Dis;e3aT5q-}}H?w>V;-dQ);;Sq*7`-g=Z= z9-+J8F?)u90}kR6KT2oX6ELfm)$5#b^2nE zBX+E2^0C5Ee(~rN*JrC)J^Qc(ZPCMpl!C(K0JYj|vX2uf98TDVOX0I4KN32VN)Ffd zQex9w4^GAJ?=RO9O*DUgRrmRom^5LxCf@F}ZikW`~3EGkX7w;kwXNk#3pufv@Q zzIz)hUq`TN7v+Hu7I`nC7n8}h7x8%f{kJ=?kCI2fk$q}`R2ipS6J6v`YLa70V?Yb0 zmIU+V^SM79ibV*pe^di?R=?bZv4cQ*SNI~BpINpD?T4wGZCKy52z#DFVC0o)0F(2m z9ZE+s2*zp;4vs^o*Bry%LMA0ooWe3`C+g=DAR}M{>YB4a< zIv2BlV>AVHeNhIR0&Ta467H40mOW=`CQ=(Teqyh`8%$_${ScRBwqjmxc_4yIdHd|z z#y&~G9vK$z{ExlI7s>Fv&xX+2L$3qxe>!$xExD;r>TH7*9m`=J+AG>w4k{SoBJg?_ z$Gm>^2X>|I6dg||S~`@{ovGqdPH)F>kd6TQ;$|YVw@|3QDy_-pRv{U@cy7H(W2-0f~cN zkq+G1<8v%F0?Wu%01C?xRq=A!)IzkCWVJ{ZN!7oPJibUeR^Kz#|9hf)<8k1!Jeeq~ z8zTO#GBy%St;BCN{DB2BzSP>PRI^X^nz(eZ>4*>JNdogte@ByZsPjCj`g#cxmTb>j z6d-8MS(GV-2d}^>@Ge_^O!MN^_b=!R07*;@LcHl%_(wbd7NzG{r}!D7>i(%vV#(VX z<87l*s%0y2?65Sc*SL@P*sE->IOxJj6^6}XC#CcnfhA0n_McjNB4XDiauOcn=_3Z! zg~xV&EP6{INvxLN%#v@{+6Fzjkem1o`Zux|d_bB_olX2bbv=QA!LYCrNR3Vg+KKYE%X%MmNNKiAq=lKM+tl2b@jX`xm{s2@B<~UCYt7Pftzd_Mv5T z$XJTu%JnQ6;`v7iQFE7Kym0<6)_H^ft^K+cW>!3ApYY)U5bi_BySpH`YEjqVgE{ol zxgW}mVCaUUiDzi#Kq{ap7_J@!A;zz_yL0>R+)SY0j0%{U8Le3oTeF?Z&t}lnJZx_+oZBg&Aa`qGo)%Om@Q<~($nu79OVtS z2lB=y3q>j}Af^^|yimU`+H7|uGfjGO)AYRsyP-r$q@L`keVK~jf#hJ1lY80E?Q)lM zpa9An-plVZ-qq=vTj?;a$$-pcZ;o(YdG(7*@8H}wlJ(UUh}2ToBszp{phsif%Z-cm zeh2|odeJ3D=u%n76S_e$-YW?6=7#{XOkC9GXsKGeB9ZFvq!UL1Gx(~3R5K8d?eHUs z_t-RH&S!HjjR1p}yCypTe=rn89tlozB&3VNRH$Y?4IqZ8{vC|U?}t4~~&2I1XR zamnfcsS1_^8bF<(qt$&~^_HpM(p|>!g9=T7@ebGIC#9;E%go!Bnt1eAwVunG6O}9O zY?yX$Di_V7d-a{tWK$cuRi)zYTO6~W?Hisa;Gh5^*?1>2NJv0H<1pnK+|2gviQY9h z!&?zAnxc?Xj2!ymQ#|TyYosb3vEpO&&DIBFm0t z@vvxU?fHI}NJH4xvEB*h^XJbxvM%+SrJok&^|aUBre3#=kQRbOJ{>>}sg1f)^5Vu- zpY!takXh=%S)J%l{dMVFRnN5}e(fe}2&GMZjl)mSCoUnAKL3NP_$U7DQXO{__6I>0 z8-6vVscpE(+HO&ZJ>aizi6yxLp&odu4jkyo2j2+R=PF5=a$rS8?7pOujK_)qrCy$4 z1%tIkO0ni5webp|Qao24wu%wbPuacHqtJ?Ew&|a;_iUX@8PDekfXu304|i;M_i>1+ zwj}d|ci_8~X%R^{{8k=hj+av>3yj$44P$|P-f2Svog&CHuI(lNNw7_=t~;cqjyJvpIptUFTNkEsuZWUnHGa}>rJ#|vF0m#nzIP38s!(fzZ#&K_)O z!lOLorZ;|)x6*}Gd+b`>ZE59>)~jEj5@I~YVpZB`pQTTVx{{AnP1zq9)AzI?zgE>R z^QJbc$=#=WJlkn~i52a357gNWQu+~o+3P6Xs{!CI>G}rj6hP}n-(OlpdmK6ip z>VK{tYLk%#0EMr_l#wS04#D;YL?1nR)PdUcA4u%f+g8V+ZP)z(e6LWGWaXc1e!`xMg8j zNf#=O6-@&h1{xbCm zcbh3XZX*rq+*Rgo!Kwz|%DD8jMz=|<2;8Yrdq`YjvHJ5^hzXOxT9-5$tL=rnBVrbg=2c6j-ba8NSDF5}uAl-A}y^ej1s9yT9BH=79%A;Y^NM}LI~S-U zGD)!|pWBBu1UB2@#}c5Lb#?o=ev=8ip$fahcHGQR5II8=rkB14PqJp0jpY-FyeD&h z!0-CSBIeEV-dE|1f}Q5MC#S%)Hmtkl7J;QcpZ{`o6#rEsFE6|lt53x1H-m+zbzmat zWF?PZ!#*Pgy#73|)ul_Bb@KV3o!ovB$#@NZc@16)m8lm~;@ZYWfX}Xs@O@RqZ3f2> zqf^Jsyzh(N;$U^6HSyqwTxKbLYLXoeC7tr4aYsT6f17jCZ(x1%*mQS}p7&8%rqMFu zTwZQsY`o6HStqh`7Zljiug_wiPB@r>dH07n6k%trY)Hpzc?~|n{5<0q;Cx`dcb8Lq zA^mo}1pCKfJY;PmS#b2g?VSE_j(y8io;O+CP&o!2WY+r7%}u1jQMaa?eK zk>Z0S+0-4q=3uJP-V~<)2tDdGB$AXpKTWo;2vpWF9NZvJ4mvpL3uyeZ`_F`3NLwfK zvHD#T(f$XY9UB_8aav)?Y>DoE6oO-7DWMt__;0!n?~SP2&Rk`MkRd11cY}%flrBWE zaHO+0DWSK;>aSzI4}x=zclZnjuoylU+F<;Aej$>-*sIu=tfaNAtx%XNhFou@IB(kT z{tOZQoon!Un+QnZY7ibM>t%mZt0UWqnKhKCreW%nq+@vYHdF?@3kDD-^)X)S#= zj>KT~!Ca@EqIzLl*GREL9)}SQNL1&JCuHu|=u;rLPdKZI=T=?*MT(sjxBwaD37GmQw?i0s&O_(aS(_Xo7o8+-i*;P;cER zRxltq+ztO;L7^F>@EfsOVn1^sI*&8AW0cA;bz3Y8TYIh?V0PpzsxRK^#DG!)a%a=n zb3XLFiRviR_J=*_pF!loUwJ;o& zAh{kA7K7@9ZpuiCfPCPxUZ75)0doHs%vsN0N$srG*>~|)p|Pr!gOI&Ke2L=3!~(Oy z1jOFWt%B=u++vD-F{epl&qV4XH10M9QPsv@EQ%K*CZ|ZFQJcf^#cf1Q|Xx8q68m+&U&~6l{I6w7R787XQ*_$(y zat4hH;LEg|)e5%g@&csG%k!gyrL3|b>&9lGyt^yxuv`Re9*Bcu3WLL) z@Zl_8kVsg0;vyFP7}`aIj~O^dBZ}hpPx6qtV06q5~v@m9w5-Zc{^TG zK*Gzw`x#*jwt!!_ad-)i;sl8NzSh@emFIT4-Q_hb9r&^SHPb2JPY9#K>FIIS$-}=W zi`4-G*JKMLO-oh`)V2^IGzAJeyj4Sf8(Nvj^^k5?LlYC{adTTmhd1r3&a1cG7a1vX zd7p=^0p-*x{wk_2(FXA3htARVlxtrFHm5+J8Ptp^%OqDoxaq%`6i%pJ&M$z66L|aH z#;FL+KTc{GYuM45x%v2#`L5W~<-MZBJ^MHaH;F(qNVUa(cDQcN344&*%@U}$O3=RA zR#(QZGES}pnJqsZAQH|^rfv>~+>#Gx{rU6zb)g9ZBCCRO=`K(M)P9D~huiYHq~)?#*Rz@;+w|A2LsCV_{b+EcSr z6aT967CLn)riYdlZfDI@*Ns3@z04D3O{>OgiXJuW06@p3XDrcfKv%eMEk2h;D>%jd zBUbBI$b-KJ+^tyQ@h3U~Js)lS=>XtDZ*hq*2xKHZ9HeC;^$^zDuepFyzqk&btlBTM_%DPELK{g|YktFP$)0XZpD- z8aLem9t7*AdA(SvkQBj|qQLD+3%>B#t|*YcqO(rZz)a-gaFaYEw<0&a2srA+HHcvG zSv;iRZ%Zan>U|fSUszoGvX}5dKF7;m(aRnVqQZCjV`;c6C{qgs1*5Svsv)ijQM2N! zlN7qOf}P~`o%Lj7#^sLaEOR}XP?a-g^R%a->g{Dz?ju_`(aVb59oYo3jR3MInp6ev zy~iZtysb>v3Ap2V2}9K79D#g&|n`5fM`(s1M=nk2l#i{6Y^+ z@PZK6ZWhE`}T_vU;%=(`d=~O24DiPtD%1+mLRF#TtTbk66^dEuR198PS zZ(;R!`{gCQ8u`Og?lmNAVH{}H-CJ&fh@Cs{DDl>8!yVkKaw+hqmIK=RVla*BJ^R)YB!RCmk7G?#DodgOl z1vNF}8z1nJLSJX;i?{9{O*$Jk)4jSOjj1*GYEr-iBd;0WOH#ARg(-Qi=OuQ2&G7Ct zAi?PqvAFl$1bz+IMB>f*Ae*`L)TIBe$YF94pCs9$6!%i2%+z+{+0Ll7-%7GI%Hi?P z_O0=tcHKHj7+>K51Z-OUo|7N?^oxpz+w7Tk@^MxM9SCKJ*eU|K z^CjJ2H=C4wr0D+K&sxK6g_s8l%n?WAf7phJZ{2StH-9H!`iew5mwl-A-qGuu4@wsF z#U5QVahlv|8l2jsia3z=>DE;!_tpJmr<=}897zYi_H@~R@3;0K`}Rq$ALOQAGp#Af zeSF`a%?v(UpP=aehqv=SMBQz@VctANo3HdN-%V|6kpr+qfC_)`&iG3x;y{2qk6cId zon5M(=Eh5{qMXxsdf$A3a62IhSj&C^`SiKCabO}4 zMA&oNcI{Q1=oC%6=LHHxLDaa8oE4M9W?C$H7AonSZlubNZ2r``zkLU6{%ZMkI@>b3 zE1w9FVz}fXI?O+cCvKuxnpy61t)dF?7n^kqCJ1B(2%?~1F`LavqUav94qWq1b*#+3 z@`MTClSBux)gC-JvSmAe5kP$RPVDYHT44^@M5_i1;+N zkQU7V=e|HaCsQt?VC!(rBZqu4w#5$Oz)pgs*f14>W|gzMnE_MhX{6V`Wa}Aj7*ysK z7ZTOkIet^8V&d+qbhJd)camYl+yK8BHtXMv2uNjPkc>9zF5pqSPwz!vb+`^iWnE; z&Q;PSH(kdUh$p#*rYMM#b4@8A3(vOZ>Cj$3GpkU=7BTK`s_-cjOdvti}-*} z4oe*>zoYThTVrC^ZN^UfqQOtuk=>&p0r*y+(>R*-y9a{VLA zRBppa`~SQ%4g&qZf7^U7d~tNLn%R{tA3o?@??H=u<9$%jgqf_bLZGGY69iE~m_ZCu z46nd$nQ4HD0FIMumvHg8aO>WLh4cXP**kE46HX&?x9-K3CMtE--ptL1Ut@mLlFgAn z1x+yN2g@^_ZKG)ATpYp9nX-|mG^#S7aaZBldtHU6xZzf~rq`(?8OtL>{|Fh(aq<3p z^GqXy20kmUzSVPG?L~lBHy--6o`ngJf1=I54_WxBe+}*}gSey1TTh126&^7yTtYu5 zyGdFaz!iyX!Yi1tH2D@qWweDtz6=!XHK0hZo z0M~EoxP4K<|4fKx`X7UHYJIW5)5CT!q0ov%;(kvU@8joC;Et&5GDJYQPX%I#wRyYq zRYH)VbUGivW>lJvyi`XdD2YYL*3+Amo+<01uZ-dOKF20n+VC((#Pv%E@WAn$R} z9bi~OvN#HPH6_v7wu}%3@YA%oQBXGgFcLZzk#P&k8W1G6_lV5C_;_1XQ&&5lgEu_~ zMvI%>D%0Tpo7`CdxA0~OaugpKqcO6QqCs^{+fpmwQ;g(exlwZC8>Y!Qr^3J{n})?^ zl$E5gq=x4G+e~7|X_Xmom5GFs-|Gcuy55B9veEOGbTiW1P?xInN{pyCfB&;T3$st; zTL&cs8Q+$Vf&i|nD~Yzdl19xdy!9Mlg5T^)`|4d$k+}X{YKu&)TGNOr#;^K^@(qz5j>%Yoa()zcx`j;7xcO*Fw z!k(u+JovZ@l$%BfPJl8M`Tc;DFyoJ>iUX)MTB=Q=03e z=A_`vLZ}B)mz5{wA>Qmk7jm9l)y2a8+lKz*?9?j-?l(i;QCj~ZFkQygJtRW?Q1Q32 z)LY*48Bt}mkURrBX3J0YkkC{}>5~J3NxEX1X?v$DC*O;8=S7)(`|L3a{1k`OI&F||viA^o7^m*}hD+;VOd%)kw zF6d_>)bLiJ1=n8{>0FL`-`?J5fNh1v+^22u-_|E864-+1>_-s9hQ>R)cU zQxLzF7V>JL*any9Uda!lpk%h7WdhWezTSGH-pE@3(M|-J)Id-#)C+}FJIq4;o8>xk ztj&bRUv|Ct|9oS=4fY#z2uipFJ8=Y#m~*@}h7NxOO6_xJh3^pHI>043?qP^e0MX7x+B-*AES_ae!93G>*uooluDaZ?Z+dV|L zaXC_+e7wzh1sc^Y*Qysk4oUGvNcG>qz2#J$4W3q!&YL#&*%s0_G3iSp86P9K{VH&A zybJ`>Lw(H0?o-vT>HO0LEr~87-n%#!`2w%}V8?lC_p@U3mw<;?z3bN4WA+A$;u}45 zj=_CQoQ;Uy|4#h_yiwDRe34pBY4uC@j$8y+!>$J3pj2SadaNp6hi9@{Q$J>7MD^@9 z$7$BEzmr)O~kR;IXubkWdF>!1=)ZD!{y@4_vQb;+2<9f^0(iROh;=`xboc z?CgWcOcofvk#iD(@%YaR;Ch>dIxlwMzxV&Ncf+7Cif&5 zd)uDY%3M*H)|@RjVqL&s-d zg6BG~dnyK6`VSpturS+SM?Zwn95u5v3pQBm(){3|9JbQNnj4M?Ad1Y8+@%XQ!`n8` zT?^4{l~GlVtlw=sqn^fC3{+ z&AncQvycSgu5)gUqPyF4aWtv0Cv4tIGCncU={a;<_hk^`DSyLMp}-bA?L)OqYf5N# ze7~zQg*mlJwMZX+*xEf^0b_dOwmqS939>O!D0QjEo9MV4*qfitG0gI)k&bhej8foo zj~a(suQkYd`F1aG77`)c()q@Y6(dWUs=RF6TwJvFDFJ=jH<;+4{YgQV?k7yCm7CZ2 zy1}F)D7x+Rub0KbJ7Un@nhAZczAf=YD6E`VlO zDo{PNlyHRX(HunI$cT5fCpB^JYUr!ln3QpZ)H^v6a?=y%*d~w*7d~|z(b030hy$(p z_qN9#BEjzjkaFxw+1!WBs9%GBL6G1W^Dytk_n7heNNDBb_p%&n~U0 z5&a`DSN1)Gz`kpWxw&(jG5+pno^hutun{?DmtgF^s<)_gOcuG zJz~Av!=&^aR-hLH!QXACTx1IGGS=^4K~M zy00zdwrW;0@X}p}^ELKCD$o~GOWH}ZTfInjGVL)d+It1Qv8!&UR@JFuL^r$mc^Kiw zPTj7P-zB=~a^kh|!`wb6|g)O4t2mMSe^TZkP63m%=%STbY@OO zZewvH#XD}=&&fyfRB3A37<}O7ntoyC=b#RPXuIQ)Hi8=8wbt=VFc{`vLdO4na9!_ zz@imCnLI;W($tq+yPiYO4qeY&oD6t6u@%;#{hM;^pzlwS5Ic)8DJ3(CT(8~pzO6VY z#NYn#*_AHqI=f|i{~w=5z%SrjgdY)7mZFANPHIR>NV%0(#8*LL7XNJ)90M+KF)^Go zhoXv6m#F0k?&9`ZN%n4cRe2^zNUC$=_>lF*+UIDL!=uCB!1`9+HN2PFlPNtbQlddR z)m^jO6FHwG(-?_ee}TCQr7?!9>$01&W+6;)uhB{QdJYJd6xZ*ow26+v%|A3}QubMo zK*}4oh)pqIgyVf!2HqyR$$xHDpu2CCSg^HE>g?%9x(83X{AlnhXd%uEMG;W}9#lG| zn(B(`x%ZDj5kfqN{gTC4uvU8ushU{Q2I2{DXe`x z1TJ$GPrJQa&ZNX4Y>*w5rhC0vZe{#yrvHYwLmDHURt*Ug2hDF87`5Avs1A>q&2Se< zAw$QVsTxtA!)ho`1%{r)zxA8zvz>2p>{8sNJX4h|5pIw0eG_|1NWF(VPwK(CVW036 zuT&s(irEyl?7Z3bEygW(aXe%bJpot;i@$f;??%6I2+z0yHDD_(Vk%L@7eF?bkylHwpFCO=mGD#7<(NJfBB19P;W(_}vQjs!10a=h#oB<*P2n(+jjwc6+Sy^@$0Cgk{Y z?LFAAsRjhZhK1SVW$gDe-c#N)(3e4)#YSoh^RMdOd%A{rv-m;8>M0+n>wAjY^k+q7 zXxb=!By5;C7IUoIDpl?Mo8zE($2A7O-DwQw-%$}wRMPLmLCOYQ9rOzw%%qW_1kbr9 z4dGw?zBj%mj{DAr|Eq(IO-ZTt{r7JkRAAu3c%fBh4_{xkNng%`&05B!%p2=uUn?eD zsEx5!QZLYtrj5K6s6gpT^*96YM6;nh@qe;cwIj2tl*ibpxClWcoCPm>%~9^CD9A zh^C0TdV@PwcikZ16Oi-2hOUi#i(;)8yqWQh0HCD{WTk`4q1W_TIDXo3dV!$Bb3psv z5kwIpZmim`Yv@=Zv+9P+WP1i!YUa<#T(+Yr6sx54lU}e>5UQEWgg8`1;RhD_p5dHk z=~qu$baWAYaH9ND-jgIC&mPy2c7{91M64_nSn@*shNU?2&Z}l?;E0smeOrRlsk4)r7{-M#UYW$PjE;?4#w zG1IqMd&V$zf0QwCbGE}IaC?g%`xqbIQo@6C(RLr5m*LV`_#nepH5y&b@ieLwIQuhu ziItvE=K+OCe*Gu@&;-L-@JqFwRZY_wWhXlxX>CPs1x&gZjlU<-BAJICI0U)@F78{g zC%4f_m>0vt#SQU%ALo#cH>y?SZvsLQH`x(6q5d;ZOGrL|s6I&R%h5UtDSvw0;$dY$ z*hF4fnfs49A)*o_8SV~quzV_83BxHVq0f=rbMU&Hu4!QClV;<4E61%fMe_%Md6enK7{8rQX%k;{T;mREQy;r=`P*LM!XZjn zE|z3E4Yy`3oi0Z=0eTSI%!LbOONVe9)*styraS&HYF9}KZQuU8#6|puTV(3Z&@*{F z_}co)A?-W;id@>O-Z2tJy4Z~e2O!|?Ax3S>QAgX^)G`P+2Wu;Re9A0+(Fn00&Ip5( zv(i`)Kr}No+U@pJINv#-uw&Dm-8B~(yOf0_q~L9NM8PBv)LSpXZGK>@-gKTJ?Zx~*N$eUnP=?iu&2ANe&?=xv<#Rl}vb zsgRhhFl!wtrRcEJ(9;q0IS!9SH^LhP1yJ4Ue!HX!q-p4FrVUGJ*jxl1+|f(NcEm6&!7*Q=BQYz-d800KU&+(eQq<@)lWlI5?pMT zFZ>HHtG(g^Sg_?snCjPyIA;{(vW^=cM_SIGCj}=wWRIF#3dTQU4ze_J=L0KX58~SZ=2~-s~_O1 zim*n|wsx5 z9xp^~55%?FFJc^OLEdsZ8Na6U`ZW7f4o*Us9dKS*79Xt{#yK;dMMT@)5_@Aab1^0O zr#`_C8K?jA(`+A-0avp9oI&2mYmhil2x?km*^-sqn8>5R(`zbX@qmhAS2one+~Q+_ z-)#L>c`NAnMX5dRED|Kser5#|sjyjWwV7wUm{O7u(m+oOf{RnzW& z-#kB%)6V<~N&2;K9m4mfu1EY9D1s@E5xrSycQv7#!3n~|6P*a#!PpY?X3=Q!!|TVsr3hiUe*k`pi>j%LqR zTpXpXd(&jb6>G|Y2@z`zq_`_h$$p?i=;DNGUKJ_pDEbLEVNt8buOHbk?p1!P97a6?$~b#3xWJnRB4=E- z&t_;6$TT(fpbtt|h)V{McCk4P&mwZ2swqWcLK*beqIEi=P`NnY)a~?jhO47@h&fb7 z&W{{At76kcycX^CvD7@s^X{1HrK6aP^`xL15v!oEIm%Wk()6Uws&j8o5V8VIjm2TRu2 z`N>~DYvM1V`?^$Q6Wbv$sgjgT=Z3@4?D!w}UJQ#ECThlZD_UtL$*!Kb2UbG|3t^ND=>+oc=YhG|`o_mpM zT5sGm4KKTUjH`YH`jnv0^gR!l5#nclMDd5@5Mu%S#vF$B<{1Uvni{YEg2_WDB1iG8 zP%J&Qb)aZg62l;~*#1WI7t+I+#g=(9#~b9CNjz2qN&^B{)16_=r6L2!Rk8Q>qH@~` ztW@nJ32xD$AFe7-+?lg$I=}JPnCW*!M`(xWY2Qp#Pe6yr=^Ezz>Qp*^KxmA5&85cA z_76BNoGNn0F6{F6B%cp^k0$4|d{x7ndtH^~h@}b`9!%QyrLOlZo6bkx$y%wkILH>y z7@ZW);5)kj%Obv8yt!d!jcHY3X`t}&Ky>M_O-vdEzTtHtzKfI+ubJjQpnu$!_G=>g zO9)Ej6H3Hm-$zxnkvG~dwB=BleAHmS*#WgVeXY#bL*4yeLr$OR%uv+EyrG*vyOQRz zO-i&`8Bs~sWVtaX+`F%<^ob6{J)E|G0wPb8sBLbZEFjHSMLMQM7{ziwzVAInyO*Tt z+8lED!|X_oEb5nahk{x)myhLB*EV*3a;)Hu%CVo#2TOHc&x z@byUmFOOyEW4Do0>Fqy?Dq^e7+^f@c!opxuX*wJw&D2;Dsl(Dd03HAKn0AwaawK%Q z3+14S%lZ5u3?-UZHi0X8{t^atl(sB2N)I{i#Ut>JMiR8*D+0u#r~9Q{zqRV5iWDY^ zq;)dkrU&V0aq1IGTayp^hRGN&HN$Oq_!cy_|Jtp_L{~*_uP^9!SwVeO&zy-^@YL#L zoG=ev{btRf*{j2Cy0DwmpWLST2sDFN2K$0`sZwHR#cDv+WITPnTdd}ZO`<`~%!M*E zi{$#M>MZxxb%7-S$MxH)Sb*O>!@s*F&X?DxTt#8rnW7aZFs{YXoCkM_y;J&FqxOd7` z??m;co{qGm5iL7eKs$JaxCt%UXyF(rNgAc9YXR%yGUm2Y)^DIFd#-c>&)~q<$8`=f z&`@$QpW4!@N~7v7Ghs4>lF={2h?T%`+Qqa@V%a;+KXqRY^<;-sg^hpIJapk5z@nXB z(}4bvm??;SLxP27lJpQ%y!w(BDJ2}lmJitrE>apBnQ1=q0PgQexr%Lt46@Z|0wl2e z))tq@p+(J?BYb-Fxg)`gv>Dd*#CS@JZVI(MmSp*JCXzQh5U-=Owai4MK-2h6C4}#}X9M0=<3jiRFt;RC9wIEiW|e87ehLZ? zH;}TnZvwICy3D%RrHNn|*ExSS{`%Bi``{9a+Gl(Ev00imu^)oUuq)TkW=9j<2hFP~ zu4;Fw{%pAw0QqxuSmI2ztT@@ckIZuh=Qs>dCknhfH{X%s5mcnzE1dQS%WQ+-*8wzs z+)@$qy!ZPxX_=wJcM#a}wKAYM1rjKcF*fn~1xc}eNkcUn+=V(B?8mME4d?e)aE8Bo zM1GIx4SwM(fyVU~E-@kdsF23BBYa7^^kU~nuun;_EO9!tv<0b5Tv_VEPqxT{xJ2 z6ctj*>3r;N%6>LwYy^T9R&xLX#hB0-CTqeu9I2tebB7PKH}hzCctuW*tm60N!9m~71AxXJTn4tTrxl|Vr>?XgLrh>wOpEO9pCCtU|$PkKt}uQ z=@*+jtJeM57^0DUU|BZsYwgVO$6lnCc;)?LG<1tE$QQt+|{ z*#v4=?`$p}xrED+wZza8`nv7AbI%YJ6%+_x_~4}N2`tebA)u1lI6>IfU@<}e3gxt^ ziso+v{NB!w(r}+c3B~#6X29{-MY-UP7PV~&*cdQkA495y^bFr?F10zw;xViQw;%p_ zqnaYcOtZs4c{NO8J33l~W6d{}!E(eU;{J_Wz19NTXR~giPh0l%C&v`Wv92K9Pu$=4 z4ts1!qXZM{bk9nryQ=}o-?Eo<@s-G)4o*0oE;)!<1m^n--Xu>4H90@rBh?9lP$xr6 zzl&ZGDyQUpSWHZ&o#jX+u)6Z*vt@coov6a9DnkHP>SO&S9ujIMyG1KvY>vh>i8>G+ zzy!N=nwVtO%?0{%HMQX1K&;uys?}onBp5E>Nb}isPbF}h`OM|G0TPe7PJ!XM2F79H z?G5mncKY<5y2P#Ebz5afEKlcrkqIB@MG(;Q?Azc(y354ax%W~70sGtbBF{Q$4^3`Y zKy;hDriSwFf>bezT2HEEVYBVXEfS@ZK5ALy8ID^$4j~UR>Jz!Mr$&mOGkF3X5VE6C zQd;^rBVZ@rCc}H}yRl8{PnOfkjjza#*mBvF2&}mp-X$jJ&1sUQ-S4bBN}xKi7PXu= z{uLzo3n&bSwFfVPmN?DEKW>x@LsL3Nw8e?oy^mT{5Y~EO3UteYA zun{gXJ+3e%t^jsC{~-S~v4CGNP41N#>(t7W2F~Zdh;lnwH1*>8A)?=wr0O3~EYgr~ z;>6#^8y2H0J$KhPAc4b@@5n$g53A<=VCfe|RY2+Z5;fP-jCkY1-uQ4oV3*4MB9VRd z$u$f+zikB?m!HgW+_8!n2C(cm(AgtGoQWj)HMgQHNBELFE!ChIH0Aa$leb9?3e7Dq zXap2g<19~-f)Q6@=ZQO;J5d}2)f+?Y%b(9#r=yw?K~rUy%ae zS^UcXWIYsNVh$mDmr+=Hmg73K>=&%ehQ7WI?*q^$=NS zQ|Vgz!qeQYQ)*bk+`Bq)4CFx15D}DUGHFN1>I>wkG}(}Nc#%Zjr8!_v;q{~*60&q> zt0rVwI&fk%wIESg) z7`%424I#cm1N?_foWz{o-G{^NxCp(f+V8VJ8}wZOC2HzkY4PH=v0^IHjOLCXp-Bnq zs3b96d&JIi*YL4xh3AAN$Xyk9JZ!!vqECS*vsu}i0-x!qDq3M!$fM4m5|pzSDtV=a z#0FFmgHx0!a;;$-JDG_|;p&fi{eFdYx;y^(o%urFlb>^X*3hZlq+iHt4#QT@IbPeLCher{Pi?8^yh!s$77(&Pw(iM)zHu zWH8WU(XRJLQ-YYsmCYyt%LU8kj{jjBoJIsQTBEYo*IrwTLTHC@i{^Ozr3>u*lI3h# z*V`E+l|QaNPfgWpq|k9)M|a&Hc!W)Go9AXVG*_Cvh4P|O3)V7vvw#yVFNW$uYp{y^N^e}^O!^mp7&y%2DnagT1ohl(3u4> zyqFVcmJ`fR45sb}&Cfd)n)bW&DXh`hv@Z{jKpVovi_R&nYu8Auq3iGNbeY|2Wsut& z${GL2zTHze-_ZhU@x$hG;pzf^9R2(!DavRtX-ttIRZZOa$^@V{t9F5c-|g1J7re|n z?@PWW$0jaKK2Y{7iplpiHSpd=H9p-3o;~KJ+Gg&OtM2qna8k$XLeE9|C{%O`6zf;z z;2%&T?eig`C!|qW4NhwhNn)*CEkV2es6@~jIkkl_?cIz^%<*+L@buc~SEG~5oSc34 zY)-1}@;hrwsL3A#mvJCzy#%Ll<+q0cGi$;NYP3Bcv3wy@Lg<#1D1r%yUSFT&$2&ByE zS$PG51HrWsh}p~XfAZ0qC-Y%|(k@tCZTr#{=T5g>(d~{hgjj`{m*4npO7i-iqRGw) zm4eT}E|A(>!>LN;x~1JO6%m*WI1K^h^>(X0p|@r~R5srmiiI8t{lro<25mc&rxZuGIJGwb=6JQOCx+7b~%D(p11DjJ!;elUwE-yaT+1(qqLb3Q}qz`(#3b9 zE+~AKdIB%}`#!4EXhGBOlCFwO2^j+6gjvieu2uyiZc!pTiZ|QuC2r=)&PVll2RvE=9 zg;LR46c2mWRA9QA>=B~C@lAcgE|;#(8dPr1iFfa_NvQ4)=dF@rC)*!9)_-v&5zy1(2EdG`q|yDdnCjE;)oG^G#+_KL&v zM_Uyp$}g=c`7Bc9T&@4Dljj{3IlOrqWl(z~F7Mr;6hM?#RIWaZ0|_)4E-NnrrbHob zEB{2Rq<*j7@xt}jA`y!C^=6#jzq}-WNs3jhGYipp%>gj4>_&Pn#zFS*ZJu?YPA|b= zn4%sb=5eZ+EE82xDJ{w)Jr46%aBoBS@eYv^ZYBC=Wn~hA9XwZv=SB?_@L}2=UwwRl$IV* zAw|5vKay$a{`tu_dLH3STy8F2OVE=MG;0`2PUWsxYCs0xR zAz=An0KXGJ&jCUhHj53@tbR_w#*09^VPPWYYW43)09H70vbu8jIFtyg!9?}A9Y0K= z{ufWw;dn5dV*8;QVRuEyiVMwRft9=Q-#^D8op|^VLsj{M*^lP$+Zj|3lrEMV*Q4<- zIFZxE@ZOn8s!+20R7L#O`>sgpKMth7eHuR{bn>%eZs+Aa+EY*SOjgHDH-9!1L0+8V zG-OT_6*0)(y=5btv@crJ_P#{3LtyC%@9ld8Ho+Hcv$L~ti;Iip+1c)wJ%s+a;Z9}I z4KnbPVTm=KE-*f8Tb%B1ZLGQ2A&)Hft8&PxRG6@m6qg;@JF%fw1TSzx{2sELBF@vq zz?w}5z;_kQE(xHsP17C&b%~&TZz?~X+!X!L9;&wO0gpJH!t%M=akuUp2b|`WAe-!j zTrUHcieB0B+}zx$nV%nCJU~>vQ-Iouk<)TKpWs1$e@9GE8$;6JlW_ad&>>h04ZE4- zX;nv1cfau>`f*xUqoI=;;Y)gTFAIt*jj=rhlQR!NV0F{q39OunpkFB9RPe$Vm6Uvs zuFQ(hM?BZDPT@`^zNS`flLBeZM?qOeTMNZ-cZpfO;{i>M&f}A2Qwc))Qvh6_yn|>u zxpu+rUXGka(be0aH=DY2;_34}DLZ{TyPSr}*t3#KL(nCgzCS~zu)Dwell5uft9ztw z3&Ulj{%SDGgL*`Z_W6U1nB6iR;{0t={h6z1L}RMr_uxyNbv=x1+_}Srb8*>br+Xp` zM>QXZYT&BqZ!cK3`LRa2rWXu0)GB#Q|4< zFZbw@;6}T<)XfQ8Z5qDQr^vOd3_ljT2vxyVIp^V1iy6I_kvjE2862 zk(_OqmYvVY!oO-^Vd3NcQLQ(Omic7KGT_f!%n%dhyVmuian=)pe_zv;jNO76F{+%F zhAJ3eC~M~y>D+#3m)aY*{bEcR`My|AVnY^7;gbZ822kH_JaGAb#@f)(Q2h?4v6G_j=Eo%-WUsMJI=m_9xM^tTY{VTyM9@44qPA+QBArB@7W5$cpZpyQn!A0Cym#|2Ia@B7;k1hic z>ZShR==xC(N!y5V>u51iJOFLt9nN6`JN-tN?mCkk=BO!TIsW1B{qa6X(lyKvuk!Uj;<^AwcOjF7ZhthY)ziHpKMSHqqH~ zgS}&ydkHPgh-r=Y<$GnTSO{>Vz|+*z34`sf(lxQ=QQ~1wK7u5(W$lfgWQmeJ4{rbU zcf(CMM$5VAcDp3w^Phm0i0xq?29(~a_<8V&%NE^+;Ya9t!uX{Zz00|*|o0F zNHgQhmi7=~McJh--L!@N6pE5BpW~x8a74;>5z{U_HR#7U48&jx83D-^Um zO5-Njb27FLbFmLqQ7m6#mLyWZII}l|LwpG5Y$A-Y(cR=5kAJ>lw=|3v9yvjZ_bId0 zIj~KJW7vo0_;Y$0exJ7I8FszXTw{Vl&eoT#T)QcpU>%Xsm|VNYRp{vtuv?M3 zJ8sLoYc`ibp^qH1?;7bGiX^2{$ z8}OsST38l0x8bNTmWOSQtNng^e|Pk`{OA{)(B<-N*{yW=mGRm{xH zcn@6gugKVEJ~A{HhG?%(dN)VWjNcL;? zTbox74j_sI0w0zmtt3-=e0xvD$_!%F(t)L01z0f&djIDeeuy)>Sl|H2%PN};RT=A6 z3d9L;txx55da|N#wa4Y9#$V>%K!#isxoNE%cB=2vn<4T!(W0!ZVx>IgU7;oZkjvR> znA!9#-F1~g#QO5`7r7KZYNsK;QpW2<>!XK)$Bq+(xli3DCWR-=pV@ntM!}c|QW;er z3EM$a*Eh_FEuyI{a-hdRtMpV@Oc^v2n0)~FN@m=h$QH?B8cZZowOEPpsN<*s&tWU_ zTDaukF)4xQ+%|~FIcX<$*XI~#y>K)rLznyC40mDp)8Jna@!go8o*PCT3dPDc*S=AB zo9HC^@`OP}DM`ct587jmeaXH^AYyoR(w@LvkKPPftT3HUcF9og&Yl}at% zfX|Gff4br@loifBe}-IOHXt@=OUH<0-7#WuvF3A=D2nA9+E^-pRwTZxd-X!%)^%{KZ$og++RmGqlWfJOFkN6c_Z^JC1P8j}*XKPOXr!`MHyq&8aH6u6IHJWdMh=$XH^gKJSv~m@ke!ZN zx~8ue^cPP#gL3U8g=H3#XhxzG0SWgoZGQ%L=>48xW+tUp*?r02gs)n^o%KaKnv|AP_Sd=-Ucu>jM z1z=&F_NU;^x%)wzMCJJ518608TOUQm(IKb6(NA9*vlI=9F2wOu5n*Zdj*C#>vq@-l z1fFs1$UTJAxJ&#|o zHq&Xuj55_4$tZ?@7^{mjSazZe{3;JOzGBA4_H;e1CKIVt^_c(~c6N^>qUYPelnUtp2Z3H8esvBWK2SbJfpc zXD_OSG48}Kf)jGEZ_xD4WrX?a1Zw1s&r;n8;xpJ*QWF=e>AT-_r{g`BoZEBGQ0F=lHH>5Yo-oc)P$T-aP=kL zec}@DEh9x%{y<3h=P7feS>Q7pd`QzJ1JbBK6)vpHSSx2{c) z(6;>bHL*pXsj*sswGsuPr7QasE|&4inO9M1&b!18{@~m!Xer^O0RtY_NDUDKVoOJ7=N{jHbp-?3 zy%`MbR8Mw2etw!jJ6a+9(a#^}-;r;!RE1bK}S5+72!3P*3-CQbs}P|r)( zjt+vt`O<|;%$j-G6!^H#?=$0qLhwPpcOACm`=MP0JLKmswv9VWpx!DBF_z&}26ISC zddAx12q#Hqen5tje;xdmHD&^vvClB;-meDRA8=AN>9v?E@ebDr!{8pxDQ)}cfz$r^~Wd0me8On7ba8s$ax0pFHK@SeY`;9jx$cg; z2EDzXXl&SRL`7+7UqedG(sB6Md8R4iC?yIhvQfP_M=UpP;A-U!^7FZ1&cjh2x6Au; z+*oH*NqgHHXLY>!ma_G?79b_a5LnQA>{zR2Lj7g8>i}Orke|;hYO%cz_V~dNo|NO* zP_Z;KD5?2_jj#dcRete?HJuGZZta=-{Dk*(coP#7&KZ@Y#Ib6Jm&HlHZvy&3`t)=0 zac2N4?lTcqM;pwTHDwG%PUAcP>OWI$;Zi%T+I;$o@}9fJ7`a) zTTR<-MBV{fSA}*mu_@S2CIUwiqh*!TzlPFz>|aCqMuc|`9JHxYg>CH+Zh-zIL3P`* zJ}&#{`rT}YMu+Q8>qo-S=AnwZDkGSmpBjs~jp53xVA7AbxvMT{@u5T**2Y zO)cMc$HQY>V=i!Jxe;*aAX01&2Mb>W1HlB)Y@%)MA^j?tPQYxPwhd#c%N8mp8(_Fm zv_3Oq-j!H3ecFcJHNh!E{iqdMs0LK)?(<=4I8(6HXiT`LrEMy7 ze#r`dPAC!6K!NAd#Y%0dcT=-qGfZ-+9~{ZmhXc1cFDH*1UP%%oN5@CWtP|Z2b5Qg$Mm# zP|Qu_f7eMLg8!r1UO9xaFBm0Ck!jRxZa~Zb{HnrA$P?)skH&4|FBgR>v@A1g@N5~U z;C)#lWDE>C1ISQ+Er90_|15y7J0MwdD*!xRHI82tH^6p?plNSz$hzEluAZoDZKzOXETr1c5jcz!*JtgH4jb@B>i2x(P%L1t;fy%__|~CIsZ521~6nF;qeXXM@6la8F^lDG)H! zZ(q)TZf^Di=e)kkC)edxScNK{ABO{^x_e3pL%fB>ctZ+C)u^OwY3IB8 zmF85yfJ0}yic}R(8yWz3gzEW0rDOwCo@?CDU7TJPe12EAw)NRH{Y|K~-?BEa$vP*q z9MD^85L-?Fvd2D#$WXFO18q}%NNr%!7-HjWfNV#Q71#A&dN)C2HRRT(yF!fJs!*Yj zBXl9XjC#dpx_)k+g=V9M>L$~r5nhg)_aA8SL0iwLD_jGD7!BMT-{Vft?&eWTmg60* zoKk{|WQ7~Eg&FzP0EJ$^ zpARrhTiG6bn7ru#enJ!(LC=P!uR_(xmXu(Dw^V6!eHh7Mhs$w=1g>YRNq{Jr&y_q?O ziZh(x)6lPHx(SFkMfq~A<8KHKlEzx-d6CWqZi9fKh035HtLJz}S<~-TEsJ==B>FZH zZgLv7FUg#Ma1501-!arcqZ>z?E7y#L`4p$BH}}52xWVDy3eTUHVaFe z>L!zsTlkF8qGzSg8<#pF4uquL*r-xE9qu7v4mY5PsIReZb_%Bz70LcY6@I`-Vt)r1xx7DUVV1$k z++8xgz_`uZt`f*RfVh;CV;^*NY05!z#f2E{G+D7*&WeDDu_uPo+i(cw!Ymyg?tlPul!Q8R1#~n zS|n1x-h5kw)-s=60<^mNnUl_SbGZ*uSTKrvclvcRw7h9L19~5>p>Op+n<_9D*XqSN zwCFgb^Pc~T9NQpyvf>-VEAf+z@!qE19b$>?&03h#YQ$Is8GMIkv7BSI@OxOc2Lgv< zg#`sf+cY^Ju@C!Puh|jTwLxYy#vPSZSLvgJn@%#bIZ8-9Wu@Bbr-iG!y&5=rlQ)QQ;QalZbGKe3EmUBoB=2O+bIVamnt)#+9Iqyr7~0 z&0NDirer5p$`Oqq%$3_9Kk#?Ez`j5%>q<8SKEbk+;ze);&Tx#mv1Vk}yHkaiqtu_> zAys8I9bj9#lIxFpNQ^B7JAKL~Kr#ssvyTq*punD}lF#gw4L&-NXD zz~O#oqqP)zwcQoisW`KVr?r#ntq- zc7Nx`*|*+bLs`iJSajA^mf7+WR4Y&VWMNcT2oD-7`)!j4lyj7-n=p&fnk0AZuGK~= z;w!JN3lf8gm$^il5^pWWe0?Ct5>q&rVtg~7nL>m`Rm3-+7sFa4yYy6h7j={z{|6al z182H&->!{bZh-zRDguC!Zqld><-n#FC@7WCR5`7>nY_4mfLa-f!-I#)IK;l;I_MDw@dGm~)0+V{+7 z7>xU)zDy(#$-eD5j^jyS@r-(I7%wCI6F&|S?+-n z#B*cj;RSBvRj*ci!h!t<#00SI24;cBuyD(!$4tY*7AEREsHK%!pF2i00}m%`e^qpS z4NM6BMd{ZH_>NJCaFNxf!=0f1n}G+v;QEVW#~i>rikDoE3mqC6xnai{MvG5POB1uq z;rMd9r0D$b1F%Ld;5tsV-YuEQrbJQq$<$ykYzt(XR_~!+A|bXS)I*C+8)eD+;ybsD4(aN9N}ds?;QSy_tTtb0Q)A=4&W%2ZaI&G$SsSw$eq3HNQ99h3$rO^hP`3wx zJ}!1Eq>Ya?M_TuA#D{M0(E#^VUllbo)fqpnLe6CyGyyQ~;Lfnx-uevrEitlAQKCG0ikk_NX5oy3;z(XoKG9Vs4UVSyVAU%Kb*^@FULzdxLq9Uqr zj3-jkz0@TGdiMa@LsWUoPd$cWXRV$j}pOEe3uoPAIr(R z@i4mu<8cmW2uW2{RRiy+yC3j%Q+|1)jteb9YwN9n%G&HY2|;x;oQnK|XP@FPbp}g5 zCp!q4p|FeTNPcZwue19-?UvsIXypPK?>YcSgu&RKOgnqmMHj_Fvb72b3@ej3kN^5Z zQ^))qs=CLTjZ}Q8HLQ+co_IDuSD4(#6{WO1MlSMr9Q{r;*+873T#htZUVqweLhlPD zs^EgAqW-*Z`|1pD93vTZ!4%FhO@C9m7 zshgp=dy1_< z%)wgl9TBQEDi~}8xy-BqCw{AhxTz;pHNh$3-Hwp-Cg*N~8=iI%Zcf-<`%DNTE`IdZ znLqTUax^Lay$L9ci_0B6_%&-@ws{UK75QF*wA#n6h>9V-q8~3jQ&PWV@+c8nYl1J0 z0XY$N1f{Rj|9r_p-f~(NO{nQ%KA-5Ow;uEfiikhkgcFn#nr2@ zVj+((zKdcK=>vvvl6?T(Af2mLptgR?og&Zs*4w=QC!YCVila>R!ozLA^+6h#T{@s8 zEnvY<+E3065$E}+zA~ZpUwMQORXQtyD@U!5Pf;tPS!{5>pc7p|sFYvE2~8hwT(NVy zu(bC-e@f?}Fx{*pp}X7#(n}9yGC_O_z~0|~Zsv1jm9GD<{|Ir2di5Q~3IoB?vK zd<>D@O38nRoc{Gw4|iB(UEuDje|^xuP>J_E9};f2+8PO|`^z=j{C7wwylrnGt0#Xn zjelMqQPJ%^@SP~<3Vq$02;XfefAXoUlI}m>xFt6!?GUcdICwj&;AzcVl1z{(CNkY~&;e+W+%?_j3>@<_EA(Qy~HB z|2Z$X>^*W>?1j3UpqC;$ll~vG{1lCKRgzHaUnzcTe*db>;W#iINU6&Zq4j! z#=|Qhp;ICPC=duH{)lz|uD@dEQ+HN{SeB{&xxy_!c7<@+k^PT{JMEGC#c-tL%&fqF zhpn;^pMP_%R^^{Fw*Au6{FpiHE0Of&zRSToATTW&o=Z*?I{Lm42JV2NQsEspMUtG2m=(0E(@$eFms7 zu1Suwo<*Ck8XAazz^P&C1Jd@+^rRenaW&&4;$*8ua^_B&)v>Ll{HFR0sx_W|euXF|TesqQ-@(v&?3(%vktq)K0cP@`i?X+~f7 ztB))NPS|9F1nFFYbtdQkcu(DCPhG=};viJkjs_2RR@0M{41*woh^Mr?{QW%&mrdv@ zS)>P{=ookH;ZqB9cmUnY9TaAiKG>!$<{kGD^S@Tdy2`pu=6R}j+*bcwE^}@e(IeIM z(9GmXl40RfRNAb(a`1iYXbglYwCXj!xfR}10D=WLBv)ky;szQ__I461EyLX$5W~T~{EmE@otQcQvD0pMb^bqhD7ic*;iP$r z(vTm!;Y*KsAZnUr9q6;`Pkutq#cP&vcm=DAz4>Ek0 z`o$m=M?abR+pDOP@<@3U~B8Cvd31x zufb=Ak8ORev2MEt0TD}z1BkBVT--Exx)XuGyz+Ky8x%{^K;W`_tpuMc;rD4l>nX1F zNX0&~902zkt#=!{eTR9YkGK3LsMNlnX@g)+Y`;t$$f>B`zI~4Dz5PwtIab#X0%Qw8 zIS2AOP{97(bk7M2@9i=)KYRH;v*V!Y@C55eB$eh}eMdBU9(6oR$P2Q$3I}S7uO#*M zi`&D85TC7hM!5rC>ACGEC{a&K14kSw@AI8mXvx+a4iF*8mUf5x>psx6h+ZJ}EKOnQ z0Fh6$xZl+!v>jY%M#|obx_0*LSuHYrT*?-lD`#RQATE)b=K2_1Em>m`2#69*;8C^y zKEM?JL&*w#o7*qKX5Ibny&;angx0@$#4-D&nx_(GB244a})rOjtRSIGiC zeHqyYP3c*J9bZZuBII1=AokjJxp;X>``$k{%vi@x-d!`wpFdOI`3k)`K7~l9ML&XO zRJYI0e+0#%>4(z(%^}I=33qs&%iu|2Q=$2Ch+kPAawXvyw|l}Ee;0LJeAikME{7#f zXtfiWSsi@H-K~ZZ8}_8+~m=xptEuQi88B z&nm#0OE006{54)4{G07<=&CVfUiCXgvblDTuQ_eC@D6#SrVQd@VvGqDynP%A_gPI$ zw4r_rQnf}kkFD@qrK$XnVp&($hty&`c))LlzUh-x_OC}#{68uXaP4}cBcF&p(9v$A zl{Z#FAlaMB7rJ)UEo=OCeooTr#t3*FD~mF? z*o~n=z%_u~uh{Lp?L=P2kreEi7l&}6qK5`haS&h?VC4CFrqZ4*pWiRyuz0&hGatkN ziH>b{RCkk!9;TMEf13an%MxZ^)P2FL>e_Ye1l(gvfYC|MP%Gz$F|%B|c5Q9xDlT#2 zv|zmf?XO1GEhYaQ_mo~F?6>gAAp$vnq*s7#aE{>Fh0&_Q7iZ|)#L%PTlE2<>!fw|M zYQ#=qX7z?+OJ)AmlJk^|0#gb+o8pzMW+oj=1~-9KI=Leiixi~-kC~vR%)smZpH65_ zFi(nEM3kNB)hDiJ8!dAfO)`YlEV?yOkr=@nk75*K7Wn$Pu&7*<7iV`%_|Wa3^NTL* z8hg9HYH*Lz#)g7K|JDL{r>y6O_RWyJHV6J1d2MG9&^)m>t{S;aY87nI!g2(nW&K6C zXR)iEM__J#=6r?EuI%!&iGJ4Z?&Kv{`+bGSvinl5m5Qv_v{<7@d@i9$GOv!o@jNrk zs#6L}livVUQ}9*3rmD(&l@^Wh{9FXLEgbrs4%Lmff7F1Op_=otV@~~( zdx;llH5T0+P_VM314i(4m*~IyK(53`Dh5H`h3eTM^TD%cNaI%#+F7C#k(b&XeYor% z1H|9kvIAI`JQS8ATKWy^7&*uuHa$^_GBp>lb4gKv{iODVx%n(*XxPL^kpZKE?ag6Y zyU^{;S6$BA)mF_uQPy3-s22LX3Cq0pwy4HBTDZ?Hl7DT9X54e67fv^ z3kgXpaA%Rk1lnK4=nkLNa5p!2n1$0mv3s0;v=L!dn1 z6}?ZY-L*G#(|Vh$g0|jUVp@92)S^6ubz(e-C90(CK? z#n)<{?5lr&G@-+hY#u=NEP+luMgck#2{hccPcbXq5tZdm%^=&MX&utLbAWs zI|djn8Dx|>9Dm^SeTEJB{(=}9gWU2md1+f4=p!-+|98RMV0=>~a(HQ1ecjyPUBlMF z{?CJ=oYBUFgZ!4Jf@!CS1v308xixCiQ)ok4#X`5mV44tUVx(;{N}G0s`=29O(vRfP zgMZ}IOvGL8v0JPC|swc&{DySzU~`VaOw(hw)XuQwV^B~-{;SWTmNIk`V}Sj z#I)5ZPxG|)Ngy{**bpTbzR;4zF+W$P4jK5h5T+e&I(7@_&aBG;6Ot+bPsSx?U6130 z5gFH9@Ojl`c8mlM)B2pRFo)tV-bl*CZZc7xDLZUQ z{F(6?5{TKqJ&^cybwfoSx!PgI90{ce+=pgy!nHw9Rt}>Tf4wL9t9Mby+m0mfupeKm z6zG<}K%i8|FiVQqoBf3|rH&mGq7YkY4z3%I*qd=#$TfQe8!;nX=%*_YiGHKNCQL!& z;S{7RL*4I!WtZmpttx(^{&K2xerDhEq)xu>5~iW|r8?Y;cc*nl<+Db?a;*52PQu8z9Xfi9>rFr zh|NB#@>Z-=$|Wvp2qd*I7CB+?2lpgasNP zs4B^vp+A5p4KE_~guV&2p^Xfu9e1S9pz%UZ3x?Ozo|YJ)*VOO4z6!B>*l2LEvvR-= z{0FzU^-)C?q)$j!iA<(@?>v~u8~Q@Ev$sCKWt+|312HP&+QfEnDqujOySplOGl3f7C$oX-#+X_YT{w&#Sk~XrUT^H( z%x#fy(2kh}o^*5Xp5yBG?3LxQwB<4VqYG%x*$X1b$27U3=mbb zcVCL3zUmVNcl!Ijr$xG57DBFTOP)dy!`Aj9I?u7Xa=W7$1Rj|ji8O+K0Xfdjdij!k z<79Y59plMH&67i64y@_6rlRR0nyDsCNQu*9MO?3cDC0e{9K?24e%Wp-6kXi)-`u#z zr=H8Fbp8?1b+2~Pk%pZOnW&3*$W*pQhMlD36eDf!dQfWh`rK?yRurh(PbsiZx|3E> zzpA&=i_V3?kHy8$c?N%8|BAnH?T#x7aoI5sA7pj{MHy3A;f)lD-f26V#N$Y*h)<*B7|er@Ic3Ycr_PhC5A z(XeQJIh8>FfUT7T-L7xQDOh3>AkRa^vrgl3enF_RGBq=jQLSlTqDfpct9V#@{7}lg zxaTah|F^a@RleJx!WNU@q3E4s(5{aMvTpo)2c&4o(Sl>cl1a_{*(~enK(4|?8wZH> z#;uNa@X9*&KuR=p^%caA{M2t42`U-hOMd3~fYT$Mi+chq z>pC?+XH(zx6>fKWZL4`gmqegNdbYO<s0AAPd8t6k#REIoEbzVPS@OU)#-e5 zcIsJM^aIi5b1$C9Scc28BwJzBrlJlU+{JPSUwW$yI5HVbYM}mwt6BvPN`!qDcZV!S zb<+;`c^CT&b7FrOG>4yZ%7OyP@7bZB!xU&DFR{9I`kn4nl`~F}&=oIKraz8K4@C!3 z1;VdnTbclTz@_wwVlK1VV+8)g&q+ttzXc><(Aifh6lc!^sl$QRNUOIsIYteG_bC~i zeJGOOsHiLI^)w};1Leowi-8W4Orc8goz8%(5Va1hkouJMYAB;y2l&&5?9f<;5G*!R1|79AYw(r!~;GI ze9d9ipwjT%#p=z&ePkn=WB!UOX`}P3&bwDdLB7Y|9m#+jt)@t5Oo=OV<;rqLA|gY> zUR&TRHE!y5VTo_bLY)`{HGl`!(A#%zv$Ar{z4|OqN3L>33SJA&J+j)X;(0f<(lAi& znckn>xw^*~8=7rDCYxocsqQurd3azbz64B zz?}tJIZMwLSG2i|JfvX_IUVGD^Rbxd4r+cPlNTwhwovBMdZMPt=wo~7+D-AOW%Bb+ z@Z-Lmlf^SR4f+`+f$S)`jZn|AGazqdSr}NQB*KjD23fTT(FaJ6rPY3fhO!zOdj8T- zmh1!1YM~(HOrfjV9({wnbJ5!Y*#xp!6NRgCQS6+ zb11Z*Dqa7$hsMssmUbS*-7EGTpP?m>c1wOyEmrMS+E*woDgtRd^K`lc0~UDBY3!Zy z`H>3uIu?U^IDGUE6VUvv9Dc)seQM0_v?kKf+@WN zwWbUJzje%*{Pq3$Ed>*cRz}8+>JDiSC zjMD2BMzs=_oz#f<*y+_0S$mZoGpumhq@@+?WUBPIiau@3{5h14QZ9gAAK&NBcI-tG zDH?Zc`Awxc�_B$KlcXE5qfHu!1_vykZCu`teG_u#_2=n74*&y-99-_zigmj{cws zybv`R>$O^63~lIfxWneta}PuO~A_^urn{m%)EHts=LbFr)v8)HJ(`w;XPKFSkP6-=7&S&_z^0e3q;P6 z`g~8!87^k7?iQZZD@hAUkes-~?(42~_v_o|D@krjcI(FX-vWKo+#Jt&vgp01=WKxD z(W@UDmmwe0Fz_JfSuCSSm4eJ{9Gpeny?tS#h%;TpmwhxWU zx>BmEw_b5mi;{}(HI4J5V7UiZjI7>uGcz-C?SAn(bRbjlu5~=;(aR&p=S;E+`ptD{ z$Kx5*>ZulJ#6RzH>E}@+vaPsvotXhJkXNjxsy#Wmk7?@E7;F8f)KBZp!2)sP=s;}s z9FS;Q=}rMwIQz~)<;L3kUVyv}Ty=$e_vBbSxeyB5F2oQ>CyMcr3Jlse6^Ga3ALXSi zoiRH(MU!AW-6cWM7&HM zqk2u5lG9-f443|q;h*7JXnozKa6(+qb;tAd)}6J`ZG4}Lq~1m4c50scSP{?arCX0_ zxk{;+3#ihYLVwk^N2HrP)s@!{iXXhxx1Azc9R?u%O=Js5BkW(3(zQa# zwShwSDmVw8J5fwy44MKb8S57)Ep+B|+p@K`ViAPYzfgz?;STbCu1-4akUHqnqizzh zV{r+PPM^CxKVkxoZ-~zX@~D5rXn-q5&^FI`wJTZD8C*;vADPr1Lz~tEOQilGQ>7x>bGc{;WQKQoBVN>~A&|~+ z`n)jP0pKg$t^nXlnMp0wg;@Apc3Rn*VcDTtcApiqT0Q+50IfqxG9%?07{Se$fbQ5i z?jo+RoL)3F(}C|B(CBB$*PEzFiIR)y+NW|Fa}eRR#-EyAzrWmpfcp)BW}FtbA706{g^nU`RN>><#Btgj39qd%22LaTP z=}YOX?1vHq$`#tqm>2R_cTnS_`xujN%jh6+PR33&J(_-^$|Kz=!B@sM+F9HAE_zh2h4yj5s(P&L6iKCn%{)Rkbr~qH)>t zMl}Eh(w`bV!N_b$BxstyYxODN6CT>LC*vmL+c*8zrLz=`JmKAh#< zrzhhbxkN1}*?e}f@obz}dbmIaIxzD%w1iixT2<67wx91Z52`9QEdvl^t~EyHXn^8_ z5LE=kRzE8FgphFO)ALId5|=P4W6sfLEd80mPAVw`x`Jot@|}VCQ(}k3phz+Uk!^CODcZDy zvNndsszk!A_k>;at{f_~pI2tiq>qGP;AXFv9;u+ZZKTfoJ{5K~atL z0(?87n&{B`qr(!<31ye6Un2a?=*P;Z1n9acdFP&yr@W})h{E(#D(z&r@$ihH!~<!hJ#)$A@{Ft_WCmnXSwM2|{m7K%#6w z@&V@hy+De+eu1X*iU9FIeI}v`Y~b!5z*;9o9_DowC8s#Eo*bm)vU0|8rnhzDT9`=2 z$C)rXZrq!0owTkH`4DGjHRI(v;(~Al?O1(_awJnvqgvS=ySZNBSVBU24$zw2gd|hhuG30=uB&iMsCmi!)6jBir3hI zN{gg|utzszBaM8mVP{>DJ=6N_{AF_G1CU;lYfJ3a3!y-mpU%>g z9rMt`7@D7C8QZ{;*DoJd@@|B7@nv+o<(edC(SiEF(Iy)K@@xIKN6veqKqz1iGNKNxh9}PZlt!DS|5MQWN78n#b-&{NnOln%qTs zC832ECJ9yqK`Kw}Lw3v8J)82Kil(SHLMd_PQoHo{S{Sh(MqXRH(&H|xi37GAef5X)KG5nd6LaXmUUX4h9)zvDZo`>UncUw&oMtloD}7=_Z{ zm#M*tOD+Ol&&^L1fiq`XV=v+@_kyj_qm|mJg|I|^;tNYOQ%60qKeRkk>BwiH)p_k{ zTI8~fho5L3RK3FDQz(@rwSJF=cd4SnL*Tlbou4>mRdO>Ex+w>Xi8FQPP0d@pyY?u0 zW5ndzi`Q#Aw@n)S3CF-U39&pb-V(dHN)oDLL8Qoe^aeSPaHpHSHeY$qU^7hLS#RAA ze%VQsAcb>l`?<1MTPSxwz|$-M(xpWNW=0RfPC*ZX(N;__?C?t26(_tr_i}!F{bxhX zzOA9LW8&%8J>WhJPxK(fQu#6o*K1zwl1#i7K_SSGLh(P_fyVabFm}}5m-0F$AVrft zHFbqt&& zT*V#C>s}n61L$ZP(I2<&ErRRWdompuv67|nt*^p5BCfjpxieujO^k+kJ$%<=UI(k` zh^D;Qv#p!+Y)OiLO{;CKAM->YGiWrF4V0ILy1b@hg0~iW9MUCT+8;R52zGd!E$vYu{l8vHM>kDr^wEh(TbJebtNY5fH)@*0Z=a^Wz#QFq2; ztsYeAHz8m`2MP?W8)s<_<@5*$!o@RO!xW0O!I0nwA4Pzq4R>deM%kTg7dWR&4xMq7 ze{&XY>~NfHc$r;_3NczU)-&xBR zg2jG!N?ez|n zB_Q9rc!dJ)^`b;i3@#*HFJXFzcfiK9(1$lYByGPo=Fja(f@X>$U96m%j~UY)dnTc= za`iZDu#)($%7v&}*PN`j>iW%FLAI%Bq@J-q4I6BG`$s4%rt3vhJ-@m}RU>t*fG``1 zdjs9g)z>l`(v)eQaIkglR)DQ}8tIO>fBjyihZFx?uyCG6uKGbkvp&%wbD$4`k$SF8UjyO||gZRV_25+CY;L}6w@~!4=lfqf zhboKbjGJ3H-fzApak1DjhLlQ-QBA7y{_hd|ba;5ScOC+JP8)~4ThA@T)vXLp$)Hu$ zy%IxI4-1VeNAd8n`=q*bN1N9*_Yl1m-`;vSa^V_Q=r51?>(@Z@27GXyA@w8cSBVQX zpB92RMGR8(k20xk8l;R42!@FV)WH!#*Mo8E5u5C;{KrxMv3_Eu2j>mtn=2vOR_deG zHjc~G!N<%*%U@XImub#N&Dec0kvF=V;HrH$A!zjbQz5Z0t^A(l4d#sz|9;`z=oi0L5G!@S+<03ES9?Q>p=ni^Fu;BZv*r}J9-Yv zem^_T4~w^Nx-Gnn`ZPR{p((2N{_Y>U{p&ADLrn29Z=yD4OsqS<0*9&;biZza?xUgW z@cFaUjo%idwzNcNW1k>02N9n;! zQbmI`l34jvfN-T`3actTZ#CcA4x0X1SNPYYekP$vf{{LCGmBS$d}OE~ZXSBL1lLvM z(z43J%d{67Y*BWf>e2f>$o49!T}d(*+S(?A*9%{EaIV_;bbQ>f*wk$6n+*3kc`fL2 zTi2w9kVXWqFsy@DNVc55z^Xi7#6=mZqC3>rK+#atP z)flQAtAf57MEH0JsHDZn)#41O8fKlxHdFZYKgAgX5+PVVJ{sCG@3wko71DYN6DY-|glNwFLeFGFq=zEroSxfZ zb@EPG8C6$AIO!@?dlTqHo^q6Un=zfeCQW;NYl?B*PrAa6{o0T8^8z)lYTvra(} zWdY?~&E*q?6&qG=%mXPv%Y|3XCODTO0H4a|nH~AU{8#YyIKTCtrL+5dyOfE7sg|UK4t% zE@1sVM}ZUiwf@WFrU4s#enEkAqDr=a&G6Y4Qwu&#SZPwd2~!-;18s&!LM!XjY2!r#|Is71;uZ$Ism$wTM+{zDd!bMj;p$ z%Oqdm7aM<3iHb*4v7Uq5*q4*)WtAn?z_U-HVz-bjlO}lfF8=wn1x-lD zlvUyu!nmt>$W(>23Mt;sFJ8#aHk3s~t&6QH*5}T&ya^F7@LqMm>^7E+cw`{5q#Xb#y0+f}x>OO;pm8oAA#OBu zawV)nakl^JA)zcV&w+;X3l%0nFP;NHB+?}O$E=O};&{c~?+az$b)lVnjDx5Qx&dk2 zyHO}FeTb&X9c~j&>(BcbPH<;1p}RfFDD4-g5MTq{4WhCi-5_1z#BD4AWo7@(HTE0_r z7(lNd@@jHan<mANPR?4g&g`fd$@mhp-^ga3R&OGd}1I93G3g4%E38!9M@5-Gw$I zWmW*C%mULhso3f@?yKM^!mQ5e&IJ9pES`>vCKi{O=O&v6oj=Fi5+o{nn$&=Z2V=?A zQz)e0(E=4WHO8+UMEWwFYBex7Hho23O4Aka#odR!e^pWxs|uo0?l#P3HdIPj;*4&` z?`?UR0yXBF98Esf;_>>Ptc{Qh8h4aYZTw)uOxxxyf7_`9X#*y;sr-1$qk_=9zPzlb ztK|y&Bkvq%Pxhyhh7`eea9yG=%cMH`((aQejVJmk6<5eH$i&)IO#@=DJtw#V+b!0i z4^kEOeIoVE6b+|4T8xYl`IO^wbWI9RQE-OVPDmkYW21**F^*VB05bD!w=lxdV ze)*;T`tukA@0>w%Gki*;QiA8E{Y4|a<*BZ;BdBR4SyC>c_xfJ!BBH?>bT#3ymb?3?UNx{7^UZ}eCmcQ&3nW1eWK^!e_FhxN6AfC5w&oOUxLnr zVlQ>DMGfox*tBa$;$r2YN~I3F0R8W|v7Q4+L+Rq4+mKd%v3}!GDCb*ez#b`e+`$c% z^&q;cFV-hPPwsO|*K{2t9SFQ|rrm#4fqCofz)9N>)kRBRQ;C4CvQvi=b+f;x&EwPp zLnW0ja^_yXsHs3JXxL7DP>lFl!ardN2pP@;ub|(@tUh=1o!R`JGT$tv@zkS?_ynfiuX+bg79(XV4+1^u1xo?Va2VPKTfq3EL#gf=srw7YFG=}u8jTEI z)_+C_a6`$}^4AYOUj9xYQp#uI*f#1jV)n!p!W=fGZ`1+cy1N7c5q==~qe{>n(S$r( zEzSNwcHDE_1>j*=`G%B1uZnZjEm!$s-cQ+1g(Ms{IFf!aOKS#F8O7fN8*VC@G7IjJ z`1bzsQs-@vjrhQm+8Rpp(8~5gdf!VdPHzTqMs{7_8aZUfLe{i0 zJk=f%66n~PIJz2#@5zezeYgcOEfeL52D+)|MbhU1YPppq_uEk_`w;jI>Vt381TO^5 zwIvU}BK2RXtTbmqabNStmL8~?!CqADrFing`qS;W8)vB74`+@jJUZ>qn-2-D2Xifk z^FNle+>u~PS;X*J$Ue*QS3sy9(|Oq!Egu9)rmk7&FdsiZ&ZpQ}e{*a+)}CJw!0fWi zQQN7WB*~2wQN9q4wPEAr?Ax5>)i`Dz5qG1C{0Xu3u!f)koceiVe zIAEG=6ae{ptD`qA7#ZuWEA@p69O1&~HPwQ$MZM>2r>S;=wzCz0@fQTkJE_Xr0XqED z>Y7?M1L`jJpm$c~Nk`=sSB?&J->j;cwLAKxO34bvElax!WJB!r7JxY4V2Or}A@Z3V zA?}a+a!p+36>r?$YJp}IA?xAE#wn*R!N&USUI;ZNmHx{iFC-c{*AuA;1Ql*H({WT< zsA9TgkfaZ#SHtE!*9mP%%c)Eg5>(b26`ZuPb>y+?{eq7J$W!yK8|j#jvxw-x@xw>S z^-ZEYseNDKeQf#^oncuG&<80x-+3 z-w#zx&8a+?kh3lnw7T z()=b$?kjW@85?HM@*~1)*Gg`-trrJ#bnPByh5k;|;@4nj-kNi8`&P{wIP?@tQIbDWdRH`ePB<|j^-WI`|IlI0(A7ycwweg&+ z54>Qke;<8UWj~}B9kS}aaj%||@usS?%4*?BT-V)P2+CPUy4?#9&F@Ci{@iYLdTeUe z=lULP7@QL-M8mv3mCoHc=6&txgYENR?R$%RBzM3Xv}hZGs`Lze7!ZJX3oCq1mL$(i z=sGkB>(n$r&Mjzl5vqtvY7aX2x@xC^o)Q9;qCX@@4Haf)`d;aqPTnCpSE;aMmdA%jQyA+ z3`4igHNy5ad9f>*+#XP0A04!SfXq~J@yep=7PlX$d^41}fnwX(%F&M4;OuN*vyEeu z4BICcH?r1q%O20lU`%YvzFzF2;&}^F6Hx$tMEUsMdKfaWxMECK(EbKqi*J`2=L4EHFQT>(z0usqA6Or1G&=K2pYL{N6Sq0k9 z3{TB+R;(vkdn*$<3y=*Y?|LrDeL-Drz%tj*pML=SIJ0^%`& zESjMDPkB$NMS3fdsw9WB3NsEbuA-;i-MCda6dSCLdQHOKUJlJ`C{hUNSG;s6py5Yb zFz5i+xhb2QR={=T4#pHKj0oMWLebOmnmec9RcP7XP-$*vW(P8%b%QR$Am+UaSFSHq ztgeN?PiQQkOboNnnqE{n7kmsQR}v0MEiyYO=`2M^W2&L%@|USY?(6lrj=|;4rvh#_ z#a8iQIcfe)N#0+~i}+C8wuSa%^*iF)SwrLca5Cw2rV*kxI?b(}({Y!c)>O(?<|D*B z2%8=@OYx`G8!CSf`*G1~w=dysac!{)k^pIzZkA@W?axAjLkcUC8mKQkSE%UtShla8 z8pD7!e7$m*)&PQgYyX%4a-SyE#30Giq)vtLCsaB74(CJgW8OH^^lq+u?9d`{S^|`? zj3hNfq#!kI^;rTqiFV$NRrtjf;Lz!V{(6fMNg$K{jj_nFS6;nBAx>3aK>@Y|I^aCb z;QO7OC}`vgxjL4U`Z3e=K7p)7t78TW=6veisomS=tc8+eC$J1RDHN;pI@Vi<0%8(0 zx&Po=ADE1y<6E&1(Hn{KU!9MTJ;>3e=hgW1gh@DcCcNwV6?G-!vEui4;0`CAdoDrm z?MjUAc3<}fdkTbFF;;&(%?gh}UB#F{A6~uW=UCvw#wK1g4b-}xi+A+4TZ753az zCSy7@{hgy_%tViMEao{tWVh=BU?{MBEFrwJw+o0j*fxXw4V zc3}kqmkCH=QSmUoKTU$nyVQAvlq0xTi(G)mZ7Gfw4AO|QKT`15);yTt;g*|(%42kWWW%yXLzaS4xZZ|8T88+x1kRblo_DTL1UmR!}(&Yj~9I3DCKz@I`I^o6dq@b90K%Ks< zj~*EKh}P(fS|r(SAQeq`>Glh$Ox}S)Zl8H_kl$6ZRT;%rU$+Wv`2lMd; z3RHu{jh#&X`T)C16kV+J@FI}y)Y|R-*`ByrwAz|1_(S3t;$>2mA2R3&CV~s<$n$A4=|d%;1z53+L|idSTF;;cT!O% zyU+hxm_HD>!tsvO+>TRONdZ=i9OTmA_8EHA){*S5BpQ+{lRf{2`V%NH{D~@Q9sNro z$ogE;l6%?k>s_QFOX#}e_YDLAY@`}@Nq6{0?3actjGOJoWz@gy&Od2jWNz3#qN1^x z{#F+ru^qpsC0b-1|LDKGv?r;NX2>wEY4}+Li&{9h7GFo*|2-ib`day7yw)9PdE#@6TBej-NOe@?yiupa+>%ZQH_$<`8UJ*>PQSx`+#PPl6hwS4E|i+xSa z{Ts7G3_+Yx!Rbnz3EN+Zv}a#8zFt8AN*S=?on6M zB+f73bg|xrzcw7O;v*uOyKPvubI?ES|DBphc7MpDxBvQdUKbrjk#{H*jo+^%Q0oj8 zK&m>dt&YKJgP`a7D_aUS+gV?ha5#W!O8w-DY1{brPB86HXx`Lzs)#1NPgYBg)wSWE-!dpKv8iPOI4rC;{ z3jWKikbwn%t$dC8`=OR2RNFMYpU-@Dg@D$`524~=(Yj*`REnP~M0`WSy|=&O@ZUq| z@qiDh-NFC!p?6Yg9p)R}&;DGIJP7iyg`*#xq2WE7_X`Uqp;9xHn*35=v-{7ikuttJ zriL;~uPv+nh-UcPs6t`I9u?S7{Od=(PF`bxN1wa1`=3WQd05w5jxheqKulLu8W+He zS&j_;^WXg%NSX#`N7#Pdi(sxo-k7!aO={JZ2W*6$`5mNyO*6r=>Gf4e|2^im=q9s8 z`qGpy!}Xg@hyGe9zj}|&*QV>n&;K6#4x!KEH`C&8?nO1MQ1kxzbn8JXynbJW-e12M zC#+y`|Jt>rmBAZ*6)C@AUSwajVWLyc&|Et!R`m-@&kdw@w5f2qPcT|H4*c^pQx^2Q zH#zRKzv35|Y{MyYofJ!ATt_z3s?v(h_;0un7SuGcW^Ro;-uiP9Vf-+~@BI<2h%t5O zAI!YgV;-Ukd3qcDKhsVaH<037(je@jZP;uQ{xgtgDJ6CZ?g36ZV=f%)qIQ36AR%Uy z2H}#ZqoKjq_iwytf0?+DMjhU#L&<0T#JZ^M-=B6632dLPtI2Wi`0M@q18yZ;uvofO z!Zak>S7G<}q=aBv{USG&QYzH+4ZnVQQ~mn^@%ITLNxVJNsT65cz~O(zdHm0o!?RJK z%)%e~Q-;XUSw%+BRM zvjf+OdJmkjupulZiNE}1QhUt_p? -Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay | Vac Research +Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay | Vac Research diff --git a/search-index.json b/search-index.json index 70b968d2..26db5657 100644 --- a/search-index.json +++ b/search-index.json @@ -1 +1 @@ -[{"documents":[{"i":1,"t":"Vac 2024 Year in Review","u":"/rlog/2024-recap","b":["Research Blog"]},{"i":57,"t":"","u":"/rlog/archive","b":["Research Blog"]},{"i":58,"t":"Decentralized Message Layer Security (De-MLS) with Waku","u":"/rlog/de-mls-with-waku","b":["Research Blog"]},{"i":105,"t":"","u":"/rlog/authors","b":["Research Blog"]},{"i":106,"t":"Zerokit optimizations: A performance journey","u":"/rlog/2025-zerokit-perf","b":["Research Blog"]},{"i":120,"t":"Building Privacy-Protecting Infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","b":["Research Blog"]},{"i":160,"t":"Device Pairing in Js-waku and Go-waku","u":"/rlog/device-pairing-in-js-waku-and-go-waku","b":["Research Blog"]},{"i":168,"t":"DNS Based Discovery","u":"/rlog/dns-based-discovery","b":["Research Blog"]},{"i":170,"t":"Vac 101: Climbing Merkle Trees","u":"/rlog/climbing-merkle-trees","b":["Research Blog"]},{"i":194,"t":"Opinion: Pseudo-ethics in the Surveillance Tech Industry","u":"/rlog/ethics-surveillance-tech","b":["Research Blog"]},{"i":213,"t":"Feasibility Study: Discv5","u":"/rlog/feasibility-discv5","b":["Research Blog"]},{"i":235,"t":"The Future of Waku Network: Scaling, Incentivization, and Heterogeneity","u":"/rlog/future-of-waku-network","b":["Research Blog"]},{"i":255,"t":"Feasibility Study: Semaphore rate limiting through zkSNARKs","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","b":["Research Blog"]},{"i":282,"t":"Fixing Whisper with Waku","u":"/rlog/fixing-whisper-with-waku","b":["Research Blog"]},{"i":303,"t":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","u":"/rlog/GossipSub Improvements","b":["Research Blog"]},{"i":323,"t":"Libp2p GossipSub IDONTWANT Message Performance Impact","u":"/rlog/gsub-idontwant-perf-eval","b":["Research Blog"]},{"i":333,"t":"Introducing nwaku","u":"/rlog/introducing-nwaku","b":["Research Blog"]},{"i":367,"t":"Large Message Handling in GossipSub: Potential Improvements","u":"/rlog/gsub-largemsg-improvements","b":["Research Blog"]},{"i":388,"t":"Scaling libp2p GossipSub for Large Messages: An Evaluation of Performance Improvement Proposals","u":"/rlog/gsub-perf-imp-comparison","b":["Research Blog"]},{"i":409,"t":"From Kademlia to Discv5","u":"/rlog/kademlia-to-discv5","b":["Research Blog"]},{"i":421,"t":"Nescience - A zkVM leveraging hiding properties","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","b":["Research Blog"]},{"i":459,"t":"Nim in Logos - 1st Edition","u":"/rlog/nim-in-logos-01","b":["Research Blog"]},{"i":469,"t":"P2P Data Sync for Mobile","u":"/rlog/p2p-data-sync-for-mobile","b":["Research Blog"]},{"i":491,"t":"","u":"/rlog/page/2","b":["Research Blog"]},{"i":512,"t":"The MDSECheck method: choosing secure square MDS matrices for P-SP-networks","u":"/rlog/mdsecheck-method","b":["Research Blog"]},{"i":530,"t":"Nescience: A User-Centric State-Separation Architecture","u":"/rlog/Nescience-state-separation-architecture","b":["Research Blog"]},{"i":606,"t":"","u":"/rlog/page/4","b":["Research Blog"]},{"i":627,"t":"","u":"/rlog/page/3","b":["Research Blog"]},{"i":648,"t":"","u":"/rlog/page/5","b":["Research Blog"]},{"i":659,"t":"Presenting JS-Waku: Waku v2 in the Browser","u":"/rlog/presenting-js-waku","b":["Research Blog"]},{"i":669,"t":"P2P Data Sync with a Remote Log","u":"/rlog/remote-log","b":["Research Blog"]},{"i":684,"t":"Verifying RLN Proofs in Light Clients with Subtrees","u":"/rlog/rln-light-verifiers","b":["Research Blog"]},{"i":714,"t":"Strengthening Anonymous DoS Prevention with Rate Limiting Nullifiers in Waku","u":"/rlog/rln-anonymous-dos-prevention","b":["Research Blog"]},{"i":740,"t":"Vac - A Rough Overview","u":"/rlog/vac-overview","b":["Research Blog"]},{"i":748,"t":"Privacy-preserving p2p economic spam protection in Waku v2","u":"/rlog/rln-relay","b":["Research Blog"]},{"i":792,"t":"RLN-v3: Towards a Flexible and Cost-Efficient Implementation","u":"/rlog/rln-v3","b":["Research Blog"]},{"i":821,"t":"Waku for All Decentralized Applications and Infrastructures","u":"/rlog/waku-for-all","b":["Research Blog"]},{"i":838,"t":"Waku Update","u":"/rlog/waku-update","b":["Research Blog"]},{"i":852,"t":"Vac 101: Membership with Bloom Filters and Cuckoo Filters","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","b":["Research Blog"]},{"i":878,"t":"Vac 101: Transforming an Interactive Protocol to a Noninteractive Argument","u":"/rlog/vac101-fiat-shamir","b":["Research Blog"]},{"i":906,"t":"[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging","u":"/rlog/waku-v2-ethereum-coscup","b":["Research Blog"]},{"i":941,"t":"Waku v1 vs Waku v2: Bandwidth Comparison","u":"/rlog/waku-v1-v2-bandwidth-comparison","b":["Research Blog"]},{"i":970,"t":"[Talk] Vac, Waku v2 and Ethereum Messaging","u":"/rlog/waku-v2-ethereum-messaging","b":["Research Blog"]},{"i":999,"t":"What's the Plan for Waku v2?","u":"/rlog/waku-v2-plan","b":["Research Blog"]},{"i":1045,"t":"Waku v2 Update","u":"/rlog/waku-v2-update","b":["Research Blog"]},{"i":1065,"t":"Waku v2 Ambient Peer Discovery","u":"/rlog/wakuv2-apd","b":["Research Blog"]},{"i":1099,"t":"Noise handshakes as key-exchange mechanism for Waku","u":"/rlog/wakuv2-noise","b":["Research Blog"]},{"i":1129,"t":"What Would a WeChat Replacement Need?","u":"/rlog/wechat-replacement-need","b":["Research Blog"]},{"i":1170,"t":"Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay","u":"/rlog/wakuv2-relay-anon","b":["Research Blog"]},{"i":1212,"t":"Exploring zkVMs: Which Projects Truly Qualify as Zero-Knowledge Virtual Machines?","u":"/rlog/zkVM-explorations","b":["Research Blog"]},{"i":1273,"t":"Join the community","u":"/community","b":["Community"]},{"i":1275,"t":"zkVM Testing Report: Evaluating Zero-Knowledge Virtual Machines for Nescience","u":"/rlog/zkVM-testing","b":["Research Blog"]},{"i":1307,"t":"Contribute","u":"/contribute","b":[]},{"i":1312,"t":"Current job openings","u":"/join-us","b":["Join Us"]},{"i":1314,"t":"","u":"/media","b":[]},{"i":1316,"t":"Privacy Policy","u":"/privacy-policy","b":[]},{"i":1336,"t":"","u":"/principles","b":[]},{"i":1360,"t":"Vac Research","u":"/research","b":[]},{"i":1362,"t":"Vac RFC Process","u":"/rfcprocess","b":[]},{"i":1364,"t":"Publications","u":"/publications","b":[]},{"i":1369,"t":"Rate Limiting Nullifier (RLN)","u":"/rln","b":[]},{"i":1386,"t":"Terms of Use","u":"/terms","b":[]},{"i":1410,"t":"Security","u":"/security","b":[]},{"i":1412,"t":"Vac Incubator Projects","u":"/vips","b":[]},{"i":1416,"t":"Vac R&D Service Units","u":"/vsus","b":[]},{"i":1436,"t":"About Vac","u":"/","b":["About Vac"]}],"index":{"version":"2.3.9","fields":["t"],"fieldVectors":[["t/1",[0,1.722,1,3.896,2,3.896,3,3.896]],["t/57",[]],["t/58",[4,2.603,5,1.733,6,3.007,7,2.336,8,3.007,9,3.007,10,1.063]],["t/105",[]],["t/106",[11,3.896,12,3.896,13,3.027,14,3.896]],["t/120",[15,3.896,16,2.769,17,3.372,18,3.372]],["t/160",[10,1.655,19,3.254,20,3.254,21,2.817,22,3.254]],["t/168",[23,4.321,24,4.321,25,3.74]],["t/170",[0,1.567,26,2.755,27,3.546,28,3.546,29,3.546]],["t/194",[30,3.254,31,3.254,32,3.254,33,3.254,34,3.254,35,3.254]],["t/213",[36,3.74,37,3.74,38,3.74]],["t/235",[10,1.15,39,3.254,40,2.529,41,2.817,42,3.254,43,3.254]],["t/255",[36,2.603,37,2.603,44,3.007,45,2.336,46,2.336,47,3.007,48,3.007]],["t/282",[10,1.527,49,4.321,50,4.321]],["t/303",[5,1.411,40,1.902,51,1.74,52,1.902,53,2.448,54,2.448,55,2.448,56,2.448,57,2.448,58,1.74]],["t/323",[5,1.876,13,2.529,51,2.313,59,2.817,60,3.254,61,3.254]],["t/333",[62,4.852,63,4.852]],["t/367",[5,1.876,51,2.313,52,2.529,64,2.817,65,3.254,66,3.254]],["t/388",[5,1.504,13,2.028,41,2.259,51,1.855,52,2.028,59,2.259,64,2.259,67,2.259,68,2.61]],["t/409",[38,4.199,69,4.852]],["t/421",[70,2.755,71,2.755,72,3.546,73,3.546,74,3.546]],["t/459",[75,3.896,76,3.896,77,3.896,78,3.896]],["t/469",[58,2.769,79,3.372,80,3.372,81,3.896]],["t/491",[]],["t/512",[7,1.902,40,1.902,82,2.448,83,2.448,84,2.448,85,2.448,86,2.448,87,2.448,88,2.448,89,2.448]],["t/530",[70,2.529,90,3.254,91,3.254,92,3.254,93,3.254,94,3.254]],["t/606",[]],["t/627",[]],["t/648",[]],["t/659",[10,1.655,21,2.817,95,3.254,96,1.769,97,3.254]],["t/669",[58,2.521,79,3.069,80,3.069,98,3.546,99,3.546]],["t/684",[100,3.254,101,2.529,102,3.254,103,3.254,104,3.254,105,3.254]],["t/714",[10,0.987,45,2.171,46,2.171,106,2.794,107,2.419,108,2.794,109,2.794,110,2.419]],["t/740",[0,1.91,111,4.321,112,4.321]],["t/748",[10,0.987,16,1.986,17,2.419,58,1.986,96,1.519,113,2.794,114,2.794,115,2.794]],["t/792",[101,2.336,116,3.007,117,3.007,118,3.007,119,3.007,120,3.007,121,3.007]],["t/821",[4,3.372,10,1.377,18,3.372,122,3.896]],["t/838",[10,1.714,123,4.199]],["t/852",[0,1.329,26,2.336,124,3.007,125,3.007,126,4.423,127,3.007]],["t/878",[0,1.329,26,2.336,128,3.007,129,3.007,130,3.007,131,3.007,132,3.007]],["t/906",[0,1.329,5,1.733,10,1.063,96,1.634,133,2.603,134,3.007,135,2.603]],["t/941",[10,1.563,96,1.634,136,3.007,137,3.007,138,3.007,139,3.007]],["t/970",[0,1.438,5,1.876,10,1.15,96,1.769,133,2.817,135,2.817]],["t/999",[10,1.377,96,2.117,140,3.896,141,3.896]],["t/1045",[10,1.527,96,2.348,123,3.74]],["t/1065",[10,1.253,25,3.069,96,1.927,142,3.546,143,3.546]],["t/1099",[10,1.15,144,3.254,145,3.254,146,3.254,147,3.254,148,3.254]],["t/1129",[149,4.321,150,4.321,151,4.321]],["t/1170",[10,1.48,16,1.986,107,2.419,152,2.794,153,2.794,154,2.794,155,2.794]],["t/1212",[71,2.028,156,2.61,157,2.259,158,2.61,159,2.61,160,2.259,161,2.259,162,2.259,163,2.259]],["t/1273",[164,4.852,165,4.852]],["t/1275",[67,2.259,70,2.028,71,2.028,160,2.259,161,2.259,162,2.259,163,2.259,166,2.61,167,2.61]],["t/1307",[168,5.53]],["t/1312",[169,4.321,170,4.321,171,4.321]],["t/1314",[]],["t/1316",[16,3.449,172,4.852]],["t/1336",[]],["t/1360",[0,2.144,173,4.852]],["t/1362",[0,1.91,174,4.321,175,4.321]],["t/1364",[176,5.53]],["t/1369",[45,3.027,46,3.027,101,3.027,110,3.372]],["t/1386",[177,4.852,178,4.852]],["t/1410",[7,4.297]],["t/1412",[0,1.91,157,3.74,179,4.321]],["t/1416",[0,1.722,180,3.896,181,3.896,182,3.896]],["t/1436",[0,2.444]]],"invertedIndex":[["101",{"_index":26,"t":{"170":{"position":[[4,4]]},"852":{"position":[[4,4]]},"878":{"position":[[4,4]]}}}],["1st",{"_index":77,"t":{"459":{"position":[[15,3]]}}}],["2024",{"_index":1,"t":{"1":{"position":[[4,4]]}}}],["ambient",{"_index":142,"t":{"1065":{"position":[[8,7]]}}}],["analysi",{"_index":152,"t":{"1170":{"position":[[27,8]]}}}],["anonym",{"_index":107,"t":{"714":{"position":[[14,9]]},"1170":{"position":[[17,9]]}}}],["applic",{"_index":122,"t":{"821":{"position":[[27,12]]}}}],["architectur",{"_index":94,"t":{"530":{"position":[[43,12]]}}}],["argument",{"_index":132,"t":{"878":{"position":[[66,8]]}}}],["bandwidth",{"_index":138,"t":{"941":{"position":[[20,9]]}}}],["base",{"_index":24,"t":{"168":{"position":[[4,5]]}}}],["bloom",{"_index":125,"t":{"852":{"position":[[25,5]]}}}],["browser",{"_index":97,"t":{"659":{"position":[[35,7]]}}}],["build",{"_index":15,"t":{"120":{"position":[[0,8]]}}}],["centric",{"_index":91,"t":{"530":{"position":[[18,7]]}}}],["choos",{"_index":84,"t":{"512":{"position":[[22,8]]}}}],["client",{"_index":104,"t":{"684":{"position":[[30,7]]}}}],["climb",{"_index":27,"t":{"170":{"position":[[9,8]]}}}],["commun",{"_index":165,"t":{"1273":{"position":[[9,9]]}}}],["comparison",{"_index":139,"t":{"941":{"position":[[30,10]]}}}],["contribut",{"_index":168,"t":{"1307":{"position":[[0,10]]}}}],["coscup",{"_index":134,"t":{"906":{"position":[[9,7]]}}}],["cost",{"_index":119,"t":{"792":{"position":[[31,4]]}}}],["cuckoo",{"_index":127,"t":{"852":{"position":[[43,6]]}}}],["current",{"_index":169,"t":{"1312":{"position":[[0,7]]}}}],["data",{"_index":79,"t":{"469":{"position":[[4,4]]},"669":{"position":[[4,4]]}}}],["de",{"_index":8,"t":{"58":{"position":[[37,3]]}}}],["decentr",{"_index":4,"t":{"58":{"position":[[0,13]]},"821":{"position":[[13,13]]}}}],["definit",{"_index":154,"t":{"1170":{"position":[[44,11]]}}}],["design",{"_index":55,"t":{"303":{"position":[[45,6]]}}}],["devic",{"_index":19,"t":{"160":{"position":[[0,6]]}}}],["discoveri",{"_index":25,"t":{"168":{"position":[[10,9]]},"1065":{"position":[[21,9]]}}}],["discv5",{"_index":38,"t":{"213":{"position":[[19,6]]},"409":{"position":[[17,6]]}}}],["dissemin",{"_index":56,"t":{"303":{"position":[[64,13]]}}}],["dn",{"_index":23,"t":{"168":{"position":[[0,3]]}}}],["do",{"_index":108,"t":{"714":{"position":[[24,3]]}}}],["econom",{"_index":114,"t":{"748":{"position":[[23,8]]}}}],["edit",{"_index":78,"t":{"459":{"position":[[19,7]]}}}],["effici",{"_index":120,"t":{"792":{"position":[[36,9]]}}}],["ethereum",{"_index":135,"t":{"906":{"position":[[34,8]]},"970":{"position":[[24,8]]}}}],["ethic",{"_index":32,"t":{"194":{"position":[[16,6]]}}}],["evalu",{"_index":67,"t":{"388":{"position":[[48,10]]},"1275":{"position":[[21,10]]}}}],["evolut",{"_index":53,"t":{"303":{"position":[[24,9]]}}}],["exchang",{"_index":147,"t":{"1099":{"position":[[24,8]]}}}],["explor",{"_index":156,"t":{"1212":{"position":[[0,9]]}}}],["feasibl",{"_index":36,"t":{"213":{"position":[[0,11]]},"255":{"position":[[0,11]]}}}],["filter",{"_index":126,"t":{"852":{"position":[[31,7],[50,7]]}}}],["fix",{"_index":49,"t":{"282":{"position":[[0,6]]}}}],["flexibl",{"_index":118,"t":{"792":{"position":[[18,8]]}}}],["futur",{"_index":39,"t":{"235":{"position":[[4,6]]}}}],["go",{"_index":22,"t":{"160":{"position":[[30,2]]}}}],["gossipsub",{"_index":51,"t":{"303":{"position":[[0,9]]},"323":{"position":[[7,9]]},"367":{"position":[[26,10]]},"388":{"position":[[15,9]]}}}],["handl",{"_index":65,"t":{"367":{"position":[[14,8]]}}}],["handshak",{"_index":145,"t":{"1099":{"position":[[6,10]]}}}],["heterogen",{"_index":43,"t":{"235":{"position":[[58,13]]}}}],["hide",{"_index":73,"t":{"421":{"position":[[30,6]]}}}],["idontw",{"_index":60,"t":{"323":{"position":[[17,9]]}}}],["impact",{"_index":61,"t":{"323":{"position":[[47,6]]}}}],["implement",{"_index":121,"t":{"792":{"position":[[46,14]]}}}],["improv",{"_index":52,"t":{"303":{"position":[[10,13]]},"367":{"position":[[47,12]]},"388":{"position":[[74,11]]}}}],["incentiv",{"_index":42,"t":{"235":{"position":[[37,16]]}}}],["incub",{"_index":179,"t":{"1412":{"position":[[4,9]]}}}],["industri",{"_index":35,"t":{"194":{"position":[[48,8]]}}}],["infrastructur",{"_index":18,"t":{"120":{"position":[[28,14]]},"821":{"position":[[44,15]]}}}],["interact",{"_index":129,"t":{"878":{"position":[[25,11]]}}}],["introduc",{"_index":62,"t":{"333":{"position":[[0,11]]}}}],["job",{"_index":170,"t":{"1312":{"position":[[8,3]]}}}],["join",{"_index":164,"t":{"1273":{"position":[[0,4]]}}}],["journey",{"_index":14,"t":{"106":{"position":[[37,7]]}}}],["js",{"_index":21,"t":{"160":{"position":[[18,2]]},"659":{"position":[[11,2]]}}}],["kademlia",{"_index":69,"t":{"409":{"position":[[5,8]]}}}],["key",{"_index":146,"t":{"1099":{"position":[[20,3]]}}}],["knowledg",{"_index":161,"t":{"1212":{"position":[[54,9]]},"1275":{"position":[[37,9]]}}}],["larg",{"_index":64,"t":{"367":{"position":[[0,5]]},"388":{"position":[[29,5]]}}}],["layer",{"_index":6,"t":{"58":{"position":[[22,5]]}}}],["leverag",{"_index":72,"t":{"421":{"position":[[19,10]]}}}],["libp2p",{"_index":59,"t":{"323":{"position":[[0,6]]},"388":{"position":[[8,6]]}}}],["light",{"_index":103,"t":{"684":{"position":[[24,5]]}}}],["limit",{"_index":46,"t":{"255":{"position":[[34,8]]},"714":{"position":[[49,8]]},"1369":{"position":[[5,8]]}}}],["log",{"_index":99,"t":{"669":{"position":[[28,3]]}}}],["logo",{"_index":76,"t":{"459":{"position":[[7,5]]}}}],["machin",{"_index":163,"t":{"1212":{"position":[[72,9]]},"1275":{"position":[[55,8]]}}}],["matric",{"_index":87,"t":{"512":{"position":[[49,8]]}}}],["md",{"_index":86,"t":{"512":{"position":[[45,3]]}}}],["mdsecheck",{"_index":82,"t":{"512":{"position":[[4,9]]}}}],["mechan",{"_index":148,"t":{"1099":{"position":[[33,9]]}}}],["membership",{"_index":124,"t":{"852":{"position":[[9,10]]}}}],["merkl",{"_index":28,"t":{"170":{"position":[[18,6]]}}}],["messag",{"_index":5,"t":{"58":{"position":[[14,7]]},"303":{"position":[[56,7]]},"323":{"position":[[27,7]]},"367":{"position":[[6,7]]},"388":{"position":[[35,9]]},"906":{"position":[[43,9]]},"970":{"position":[[33,9]]}}}],["method",{"_index":83,"t":{"512":{"position":[[14,7]]}}}],["ml",{"_index":9,"t":{"58":{"position":[[41,4]]}}}],["mobil",{"_index":81,"t":{"469":{"position":[[18,6]]}}}],["need",{"_index":151,"t":{"1129":{"position":[[32,5]]}}}],["nescienc",{"_index":70,"t":{"421":{"position":[[0,9]]},"530":{"position":[[0,10]]},"1275":{"position":[[68,9]]}}}],["network",{"_index":40,"t":{"235":{"position":[[19,8]]},"303":{"position":[[98,8]]},"512":{"position":[[67,8]]}}}],["nim",{"_index":75,"t":{"459":{"position":[[0,3]]}}}],["nois",{"_index":144,"t":{"1099":{"position":[[0,5]]}}}],["noninteract",{"_index":131,"t":{"878":{"position":[[51,14]]}}}],["nullifi",{"_index":110,"t":{"714":{"position":[[58,10]]},"1369":{"position":[[14,9]]}}}],["nwaku",{"_index":63,"t":{"333":{"position":[[12,5]]}}}],["open",{"_index":171,"t":{"1312":{"position":[[12,8]]}}}],["opinion",{"_index":30,"t":{"194":{"position":[[0,8]]}}}],["optim",{"_index":12,"t":{"106":{"position":[[8,14]]}}}],["overlay",{"_index":54,"t":{"303":{"position":[[37,7]]}}}],["overview",{"_index":112,"t":{"740":{"position":[[14,8]]}}}],["p",{"_index":88,"t":{"512":{"position":[[62,1]]}}}],["p2p",{"_index":58,"t":{"303":{"position":[[94,3]]},"469":{"position":[[0,3]]},"669":{"position":[[0,3]]},"748":{"position":[[19,3]]}}}],["pair",{"_index":20,"t":{"160":{"position":[[7,7]]}}}],["part",{"_index":153,"t":{"1170":{"position":[[36,4]]}}}],["peer",{"_index":143,"t":{"1065":{"position":[[16,4]]}}}],["perform",{"_index":13,"t":{"106":{"position":[[25,11]]},"323":{"position":[[35,11]]},"388":{"position":[[62,11]]}}}],["plan",{"_index":141,"t":{"999":{"position":[[11,4]]}}}],["polici",{"_index":172,"t":{"1316":{"position":[[8,6]]}}}],["potenti",{"_index":66,"t":{"367":{"position":[[37,9]]}}}],["present",{"_index":95,"t":{"659":{"position":[[0,10]]}}}],["preserv",{"_index":113,"t":{"748":{"position":[[8,10]]}}}],["prevent",{"_index":109,"t":{"714":{"position":[[28,10]]}}}],["privaci",{"_index":16,"t":{"120":{"position":[[9,7]]},"748":{"position":[[0,7]]},"1170":{"position":[[5,7]]},"1316":{"position":[[0,7]]}}}],["process",{"_index":175,"t":{"1362":{"position":[[8,7]]}}}],["project",{"_index":157,"t":{"1212":{"position":[[23,8]]},"1412":{"position":[[14,8]]}}}],["proof",{"_index":102,"t":{"684":{"position":[[14,6]]}}}],["properti",{"_index":74,"t":{"421":{"position":[[37,10]]}}}],["propos",{"_index":68,"t":{"388":{"position":[[86,9]]}}}],["protect",{"_index":17,"t":{"120":{"position":[[17,10]]},"748":{"position":[[37,10]]}}}],["protocol",{"_index":130,"t":{"878":{"position":[[37,8]]}}}],["pseudo",{"_index":31,"t":{"194":{"position":[[9,6]]}}}],["public",{"_index":176,"t":{"1364":{"position":[[0,12]]}}}],["qualifi",{"_index":159,"t":{"1212":{"position":[[38,7]]}}}],["r&d",{"_index":180,"t":{"1416":{"position":[[4,3]]}}}],["rate",{"_index":45,"t":{"255":{"position":[[29,4]]},"714":{"position":[[44,4]]},"1369":{"position":[[0,4]]}}}],["relay",{"_index":155,"t":{"1170":{"position":[[65,5]]}}}],["remot",{"_index":98,"t":{"669":{"position":[[21,6]]}}}],["replac",{"_index":150,"t":{"1129":{"position":[[20,11]]}}}],["report",{"_index":167,"t":{"1275":{"position":[[13,7]]}}}],["research",{"_index":173,"t":{"1360":{"position":[[4,8]]}}}],["review",{"_index":3,"t":{"1":{"position":[[17,6]]}}}],["rfc",{"_index":174,"t":{"1362":{"position":[[4,3]]}}}],["rln",{"_index":101,"t":{"684":{"position":[[10,3]]},"792":{"position":[[0,3]]},"1369":{"position":[[24,5]]}}}],["rough",{"_index":111,"t":{"740":{"position":[[8,5]]}}}],["scale",{"_index":41,"t":{"235":{"position":[[28,8]]},"388":{"position":[[0,7]]}}}],["secur",{"_index":7,"t":{"58":{"position":[[28,8]]},"512":{"position":[[31,6]]},"1410":{"position":[[0,8]]}}}],["semaphor",{"_index":44,"t":{"255":{"position":[[19,9]]}}}],["separ",{"_index":93,"t":{"530":{"position":[[32,10]]}}}],["servic",{"_index":181,"t":{"1416":{"position":[[8,7]]}}}],["sp",{"_index":89,"t":{"512":{"position":[[64,2]]}}}],["spam",{"_index":115,"t":{"748":{"position":[[32,4]]}}}],["squar",{"_index":85,"t":{"512":{"position":[[38,6]]}}}],["state",{"_index":92,"t":{"530":{"position":[[26,5]]}}}],["strengthen",{"_index":106,"t":{"714":{"position":[[0,13]]}}}],["studi",{"_index":37,"t":{"213":{"position":[[12,6]]},"255":{"position":[[12,6]]}}}],["subtre",{"_index":105,"t":{"684":{"position":[[43,8]]}}}],["surveil",{"_index":33,"t":{"194":{"position":[[30,12]]}}}],["sync",{"_index":80,"t":{"469":{"position":[[9,4]]},"669":{"position":[[9,4]]}}}],["talk",{"_index":133,"t":{"906":{"position":[[0,5]]},"970":{"position":[[0,6]]}}}],["tech",{"_index":34,"t":{"194":{"position":[[43,4]]}}}],["term",{"_index":177,"t":{"1386":{"position":[[0,5]]}}}],["test",{"_index":166,"t":{"1275":{"position":[[5,7]]}}}],["through",{"_index":47,"t":{"255":{"position":[[43,7]]}}}],["toward",{"_index":117,"t":{"792":{"position":[[8,7]]}}}],["transform",{"_index":128,"t":{"878":{"position":[[9,12]]}}}],["tree",{"_index":29,"t":{"170":{"position":[[25,5]]}}}],["truli",{"_index":158,"t":{"1212":{"position":[[32,5]]}}}],["unit",{"_index":182,"t":{"1416":{"position":[[16,5]]}}}],["unstructur",{"_index":57,"t":{"303":{"position":[[81,12]]}}}],["updat",{"_index":123,"t":{"838":{"position":[[5,6]]},"1045":{"position":[[8,6]]}}}],["us",{"_index":178,"t":{"1386":{"position":[[9,3]]}}}],["user",{"_index":90,"t":{"530":{"position":[[13,4]]}}}],["v1",{"_index":136,"t":{"941":{"position":[[5,2]]}}}],["v2",{"_index":96,"t":{"659":{"position":[[25,2]]},"748":{"position":[[56,2]]},"906":{"position":[[27,2]]},"941":{"position":[[16,3]]},"970":{"position":[[17,2]]},"999":{"position":[[25,3]]},"1045":{"position":[[5,2]]},"1065":{"position":[[5,2]]}}}],["v3",{"_index":116,"t":{"792":{"position":[[4,3]]}}}],["vac",{"_index":0,"t":{"1":{"position":[[0,3]]},"170":{"position":[[0,3]]},"740":{"position":[[0,3]]},"852":{"position":[[0,3]]},"878":{"position":[[0,3]]},"906":{"position":[[17,4]]},"970":{"position":[[7,4]]},"1360":{"position":[[0,3]]},"1362":{"position":[[0,3]]},"1412":{"position":[[0,3]]},"1416":{"position":[[0,3]]},"1436":{"position":[[6,3]]}}}],["verifi",{"_index":100,"t":{"684":{"position":[[0,9]]}}}],["virtual",{"_index":162,"t":{"1212":{"position":[[64,7]]},"1275":{"position":[[47,7]]}}}],["vs",{"_index":137,"t":{"941":{"position":[[8,2]]}}}],["waku",{"_index":10,"t":{"58":{"position":[[51,4]]},"160":{"position":[[21,4],[33,4]]},"235":{"position":[[14,4]]},"282":{"position":[[20,4]]},"659":{"position":[[14,5],[20,4]]},"714":{"position":[[72,4]]},"748":{"position":[[51,4]]},"821":{"position":[[0,4]]},"838":{"position":[[0,4]]},"906":{"position":[[22,4]]},"941":{"position":[[0,4],[11,4]]},"970":{"position":[[12,4]]},"999":{"position":[[20,4]]},"1045":{"position":[[0,4]]},"1065":{"position":[[0,4]]},"1099":{"position":[[47,4]]},"1170":{"position":[[0,4],[60,4]]}}}],["wechat",{"_index":149,"t":{"1129":{"position":[[13,6]]}}}],["what'",{"_index":140,"t":{"999":{"position":[[0,6]]}}}],["whisper",{"_index":50,"t":{"282":{"position":[[7,7]]}}}],["year",{"_index":2,"t":{"1":{"position":[[9,4]]}}}],["zero",{"_index":160,"t":{"1212":{"position":[[49,4]]},"1275":{"position":[[32,4]]}}}],["zerokit",{"_index":11,"t":{"106":{"position":[[0,7]]}}}],["zksnark",{"_index":48,"t":{"255":{"position":[[51,8]]}}}],["zkvm",{"_index":71,"t":{"421":{"position":[[14,4]]},"1212":{"position":[[10,6]]},"1275":{"position":[[0,4]]}}}]],"pipeline":["stemmer"]}},{"documents":[{"i":3,"t":"Nescience","u":"/rlog/2024-recap","h":"#nescience","p":1},{"i":5,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights","p":1},{"i":7,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward","p":1},{"i":9,"t":"Token Economics (TKE)","u":"/rlog/2024-recap","h":"#token-economics-tke","p":1},{"i":11,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-1","p":1},{"i":13,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-1","p":1},{"i":15,"t":"Quality Assurance (QA)","u":"/rlog/2024-recap","h":"#quality-assurance-qa","p":1},{"i":17,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-2","p":1},{"i":19,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-2","p":1},{"i":21,"t":"RFC","u":"/rlog/2024-recap","h":"#rfc","p":1},{"i":23,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-3","p":1},{"i":25,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-3","p":1},{"i":27,"t":"Applied Cryptography and ZK (ACZ)","u":"/rlog/2024-recap","h":"#applied-cryptography-and-zk-acz","p":1},{"i":29,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-4","p":1},{"i":31,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-4","p":1},{"i":33,"t":"P2P","u":"/rlog/2024-recap","h":"#p2p","p":1},{"i":35,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-5","p":1},{"i":37,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-5","p":1},{"i":39,"t":"Distributed Systems Testing (DST)","u":"/rlog/2024-recap","h":"#distributed-systems-testing-dst","p":1},{"i":41,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-6","p":1},{"i":43,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-6","p":1},{"i":45,"t":"Nim","u":"/rlog/2024-recap","h":"#nim","p":1},{"i":47,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-7","p":1},{"i":49,"t":"Smart Contracts (SC)","u":"/rlog/2024-recap","h":"#smart-contracts-sc","p":1},{"i":51,"t":"Highlights","u":"/rlog/2024-recap","h":"#highlights-8","p":1},{"i":53,"t":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-7","p":1},{"i":55,"t":"Heading into 2025","u":"/rlog/2024-recap","h":"#heading-into-2025","p":1},{"i":60,"t":"Introduction","u":"/rlog/de-mls-with-waku","h":"#introduction","p":58},{"i":62,"t":"Background","u":"/rlog/de-mls-with-waku","h":"#background","p":58},{"i":63,"t":"MLS","u":"/rlog/de-mls-with-waku","h":"#mls","p":58},{"i":65,"t":"Waku","u":"/rlog/de-mls-with-waku","h":"#waku","p":58},{"i":67,"t":"de-MLS","u":"/rlog/de-mls-with-waku","h":"#de-mls","p":58},{"i":69,"t":"Waku Integration","u":"/rlog/de-mls-with-waku","h":"#waku-integration","p":58},{"i":71,"t":"Flow","u":"/rlog/de-mls-with-waku","h":"#flow","p":58},{"i":73,"t":"1. Steward joins the welcome topic","u":"/rlog/de-mls-with-waku","h":"#1-steward-joins-the-welcome-topic","p":58},{"i":75,"t":"2. Group initialization","u":"/rlog/de-mls-with-waku","h":"#2-group-initialization","p":58},{"i":77,"t":"3. Emitting Group Anouncement (GA) by Steward","u":"/rlog/de-mls-with-waku","h":"#3-emitting-group-anouncement-ga-by-steward","p":58},{"i":79,"t":"4. User joins the welcome topic","u":"/rlog/de-mls-with-waku","h":"#4-user-joins-the-welcome-topic","p":58},{"i":81,"t":"5. User creates its key package","u":"/rlog/de-mls-with-waku","h":"#5-user-creates-its-key-package","p":58},{"i":83,"t":"6. Steward receives the User's key package","u":"/rlog/de-mls-with-waku","h":"#6-steward-receives-the-users-key-package","p":58},{"i":85,"t":"7. Creation of Voting proposals","u":"/rlog/de-mls-with-waku","h":"#7-creation-of-voting-proposals","p":58},{"i":87,"t":"8. Voting for proposal","u":"/rlog/de-mls-with-waku","h":"#8-voting-for-proposal","p":58},{"i":89,"t":"9. Creating commit message","u":"/rlog/de-mls-with-waku","h":"#9-creating-commit-message","p":58},{"i":91,"t":"10. Sending messages","u":"/rlog/de-mls-with-waku","h":"#10-sending-messages","p":58},{"i":93,"t":"11. Applying welcome message","u":"/rlog/de-mls-with-waku","h":"#11-applying-welcome-message","p":58},{"i":95,"t":"Benchmark","u":"/rlog/de-mls-with-waku","h":"#benchmark","p":58},{"i":97,"t":"Potential drawbacks and countermeasures","u":"/rlog/de-mls-with-waku","h":"#potential-drawbacks-and-countermeasures","p":58},{"i":99,"t":"Conclusion","u":"/rlog/de-mls-with-waku","h":"#conclusion","p":58},{"i":101,"t":"Future Work","u":"/rlog/de-mls-with-waku","h":"#future-work","p":58},{"i":103,"t":"References","u":"/rlog/de-mls-with-waku","h":"#references","p":58},{"i":108,"t":"Background","u":"/rlog/2025-zerokit-perf","h":"#background","p":106},{"i":110,"t":"The Challenge","u":"/rlog/2025-zerokit-perf","h":"#the-challenge","p":106},{"i":112,"t":"The importance of benchmarks","u":"/rlog/2025-zerokit-perf","h":"#the-importance-of-benchmarks","p":106},{"i":114,"t":"Benchmarking with Rust's criterion crate","u":"/rlog/2025-zerokit-perf","h":"#benchmarking-with-rusts-criterion-crate","p":106},{"i":116,"t":"Promising results","u":"/rlog/2025-zerokit-perf","h":"#promising-results","p":106},{"i":118,"t":"Conclusion","u":"/rlog/2025-zerokit-perf","h":"#conclusion","p":106},{"i":122,"t":"Intro","u":"/rlog/building-privacy-protecting-infrastructure","h":"#intro","p":120},{"i":124,"t":"About","u":"/rlog/building-privacy-protecting-infrastructure","h":"#about","p":120},{"i":126,"t":"Why build privacy-protecting infrastructure?","u":"/rlog/building-privacy-protecting-infrastructure","h":"#why-build-privacy-protecting-infrastructure","p":120},{"i":128,"t":"Web3 infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","h":"#web3-infrastructure","p":120},{"i":130,"t":"ZK for privacy-protecting infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","h":"#zk-for-privacy-protecting-infrastructure","p":120},{"i":132,"t":"Waku","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku","p":120},{"i":134,"t":"Waku - adaptive nodes","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku---adaptive-nodes","p":120},{"i":136,"t":"Waku - protocol interactions","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku---protocol-interactions","p":120},{"i":138,"t":"Waku - Network","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku---network","p":120},{"i":140,"t":"Dealing with network spam and RLN Relay","u":"/rlog/building-privacy-protecting-infrastructure","h":"#dealing-with-network-spam-and-rln-relay","p":120},{"i":142,"t":"RLN - Overview and Flow","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln---overview-and-flow","p":120},{"i":144,"t":"RLN - Circuit","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln---circuit","p":120},{"i":146,"t":"RLN - Shamir's secret sharing","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln---shamirs-secret-sharing","p":120},{"i":148,"t":"RLN Relay","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln-relay","p":120},{"i":150,"t":"RLN Relay cross-client testnet","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln-relay-cross-client-testnet","p":120},{"i":152,"t":"Private settlement / Service credentials","u":"/rlog/building-privacy-protecting-infrastructure","h":"#private-settlement--service-credentials","p":120},{"i":154,"t":"Zerokit","u":"/rlog/building-privacy-protecting-infrastructure","h":"#zerokit","p":120},{"i":156,"t":"Other research","u":"/rlog/building-privacy-protecting-infrastructure","h":"#other-research","p":120},{"i":158,"t":"Summary","u":"/rlog/building-privacy-protecting-infrastructure","h":"#summary","p":120},{"i":162,"t":"Device Pairing","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"#device-pairing","p":160},{"i":164,"t":"Conclusion","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"#conclusion","p":160},{"i":166,"t":"References","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"#references","p":160},{"i":172,"t":"Introduction","u":"/rlog/climbing-merkle-trees","h":"#introduction","p":170},{"i":174,"t":"Tree structure","u":"/rlog/climbing-merkle-trees","h":"#tree-structure","p":170},{"i":176,"t":"Merkle trees","u":"/rlog/climbing-merkle-trees","h":"#merkle-trees","p":170},{"i":178,"t":"Construction","u":"/rlog/climbing-merkle-trees","h":"#construction","p":170},{"i":180,"t":"Merkle tree intregrity","u":"/rlog/climbing-merkle-trees","h":"#merkle-tree-intregrity","p":170},{"i":182,"t":"Proof of membership","u":"/rlog/climbing-merkle-trees","h":"#proof-of-membership","p":170},{"i":184,"t":"Extensions of Merkle trees","u":"/rlog/climbing-merkle-trees","h":"#extensions-of-merkle-trees","p":170},{"i":186,"t":"Sparse Merkle trees","u":"/rlog/climbing-merkle-trees","h":"#sparse-merkle-trees","p":170},{"i":188,"t":"Proof of nonmembership","u":"/rlog/climbing-merkle-trees","h":"#proof-of-nonmembership","p":170},{"i":190,"t":"Verkle Trees","u":"/rlog/climbing-merkle-trees","h":"#verkle-trees","p":170},{"i":192,"t":"References","u":"/rlog/climbing-merkle-trees","h":"#references","p":170},{"i":196,"t":"Preface","u":"/rlog/ethics-surveillance-tech","h":"#preface","p":194},{"i":198,"t":"Spotlight on an industry","u":"/rlog/ethics-surveillance-tech","h":"#spotlight-on-an-industry","p":194},{"i":200,"t":"A typical response","u":"/rlog/ethics-surveillance-tech","h":"#a-typical-response","p":194},{"i":202,"t":"Ethics != the law","u":"/rlog/ethics-surveillance-tech","h":"#ethics--the-law","p":194},{"i":203,"t":"The law is trailing behind","u":"/rlog/ethics-surveillance-tech","h":"#the-law-is-trailing-behind","p":194},{"i":205,"t":"The law depends on ethics","u":"/rlog/ethics-surveillance-tech","h":"#the-law-depends-on-ethics","p":194},{"i":207,"t":"International law is vague and exploitable","u":"/rlog/ethics-surveillance-tech","h":"#international-law-is-vague-and-exploitable","p":194},{"i":209,"t":"Conclusion","u":"/rlog/ethics-surveillance-tech","h":"#conclusion","p":194},{"i":211,"t":"References","u":"/rlog/ethics-surveillance-tech","h":"#references","p":194},{"i":215,"t":"Motivating Problem","u":"/rlog/feasibility-discv5","h":"#motivating-problem","p":213},{"i":217,"t":"Overview","u":"/rlog/feasibility-discv5","h":"#overview","p":213},{"i":219,"t":"Feasbility","u":"/rlog/feasibility-discv5","h":"#feasbility","p":213},{"i":221,"t":"CPU & Memory Usage","u":"/rlog/feasibility-discv5","h":"#cpu--memory-usage","p":213},{"i":223,"t":"NAT on Cellular Data","u":"/rlog/feasibility-discv5","h":"#nat-on-cellular-data","p":213},{"i":225,"t":"Topic Tables","u":"/rlog/feasibility-discv5","h":"#topic-tables","p":213},{"i":227,"t":"Finding a node","u":"/rlog/feasibility-discv5","h":"#finding-a-node","p":213},{"i":229,"t":"Results","u":"/rlog/feasibility-discv5","h":"#results","p":213},{"i":231,"t":"General Thoughts","u":"/rlog/feasibility-discv5","h":"#general-thoughts","p":213},{"i":233,"t":"Acknowledgements","u":"/rlog/feasibility-discv5","h":"#acknowledgements","p":213},{"i":237,"t":"DOS Mitigation for Status Communities","u":"/rlog/future-of-waku-network","h":"#dos-mitigation-for-status-communities","p":235},{"i":239,"t":"A Heterogeneous Waku Network","u":"/rlog/future-of-waku-network","h":"#a-heterogeneous-waku-network","p":235},{"i":241,"t":"Reversing the Incentivization Question","u":"/rlog/future-of-waku-network","h":"#reversing-the-incentivization-question","p":235},{"i":243,"t":"RLN and Service Credentials","u":"/rlog/future-of-waku-network","h":"#rln-and-service-credentials","p":235},{"i":245,"t":"Waku Network: Ethereum or Cosmos?","u":"/rlog/future-of-waku-network","h":"#waku-network-ethereum-or-cosmos","p":235},{"i":247,"t":"Scalability and Discovery Protocols","u":"/rlog/future-of-waku-network","h":"#scalability-and-discovery-protocols","p":235},{"i":249,"t":"Open Problems","u":"/rlog/future-of-waku-network","h":"#open-problems","p":235},{"i":251,"t":"The Evolving Waku Network","u":"/rlog/future-of-waku-network","h":"#the-evolving-waku-network","p":235},{"i":253,"t":"References","u":"/rlog/future-of-waku-network","h":"#references","p":235},{"i":257,"t":"Motivating problem","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#motivating-problem","p":255},{"i":259,"t":"Related problems","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#related-problems","p":255},{"i":261,"t":"Overview","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#overview","p":255},{"i":262,"t":"Basic terminology","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#basic-terminology","p":255},{"i":264,"t":"Basic flow","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#basic-flow","p":255},{"i":266,"t":"Rate limiting example","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#rate-limiting-example","p":255},{"i":268,"t":"Briefly on scope of 'approved users'","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#briefly-on-scope-of-approved-users","p":255},{"i":270,"t":"Technical details","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#technical-details","p":255},{"i":272,"t":"Feasibility","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#feasibility","p":255},{"i":274,"t":"Technical feasibility","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#technical-feasibility","p":255},{"i":276,"t":"Social feasibility","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#social-feasibility","p":255},{"i":278,"t":"General thoughts","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#general-thoughts","p":255},{"i":280,"t":"Acknowledgement","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#acknowledgement","p":255},{"i":284,"t":"Introduction","u":"/rlog/fixing-whisper-with-waku","h":"#introduction","p":282},{"i":286,"t":"Whisper theoretical scalability model","u":"/rlog/fixing-whisper-with-waku","h":"#whisper-theoretical-scalability-model","p":282},{"i":288,"t":"Caveats","u":"/rlog/fixing-whisper-with-waku","h":"#caveats","p":282},{"i":290,"t":"Goals","u":"/rlog/fixing-whisper-with-waku","h":"#goals","p":282},{"i":292,"t":"Model","u":"/rlog/fixing-whisper-with-waku","h":"#model","p":282},{"i":294,"t":"Takeaways","u":"/rlog/fixing-whisper-with-waku","h":"#takeaways","p":282},{"i":296,"t":"Introducing Waku","u":"/rlog/fixing-whisper-with-waku","h":"#introducing-waku","p":282},{"i":297,"t":"Motivation for a new protocol","u":"/rlog/fixing-whisper-with-waku","h":"#motivation-for-a-new-protocol","p":282},{"i":299,"t":"Briefly on Waku mode","u":"/rlog/fixing-whisper-with-waku","h":"#briefly-on-waku-mode","p":282},{"i":301,"t":"Progress so far","u":"/rlog/fixing-whisper-with-waku","h":"#progress-so-far","p":282},{"i":305,"t":"Motivitation","u":"/rlog/GossipSub Improvements","h":"#motivitation","p":303},{"i":307,"t":"Introduction","u":"/rlog/GossipSub Improvements","h":"#introduction","p":303},{"i":309,"t":"GOAL1: Low Latency Operation","u":"/rlog/GossipSub Improvements","h":"#goal1-low-latency-operation","p":303},{"i":311,"t":"GOAL2: Considering Heterogeneity In Overlay Design","u":"/rlog/GossipSub Improvements","h":"#goal2-considering-heterogeneity-in-overlay-design","p":303},{"i":313,"t":"GOAL3: Bandwidth Optimization","u":"/rlog/GossipSub Improvements","h":"#goal3-bandwidth-optimization","p":303},{"i":315,"t":"GOAL4: Handling Large Messages","u":"/rlog/GossipSub Improvements","h":"#goal4-handling-large-messages","p":303},{"i":317,"t":"GOAL5: Scalability","u":"/rlog/GossipSub Improvements","h":"#goal5-scalability","p":303},{"i":319,"t":"Summary","u":"/rlog/GossipSub Improvements","h":"#summary","p":303},{"i":321,"t":"References","u":"/rlog/GossipSub Improvements","h":"","p":303},{"i":325,"t":"Overview","u":"/rlog/gsub-idontwant-perf-eval","h":"#overview","p":323},{"i":327,"t":"Experiments","u":"/rlog/gsub-idontwant-perf-eval","h":"#experiments","p":323},{"i":329,"t":"Findings","u":"/rlog/gsub-idontwant-perf-eval","h":"#findings","p":323},{"i":331,"t":"References","u":"/rlog/gsub-idontwant-perf-eval","h":"#references","p":323},{"i":335,"t":"Background","u":"/rlog/introducing-nwaku","h":"#background","p":333},{"i":337,"t":"1. nim-waku is now known as nwaku","u":"/rlog/introducing-nwaku","h":"#1-nim-waku-is-now-known-as-nwaku","p":333},{"i":339,"t":"2. Improvements in stability and performance","u":"/rlog/introducing-nwaku","h":"#2-improvements-in-stability-and-performance","p":333},{"i":341,"t":"3. Improvements in interoperability","u":"/rlog/introducing-nwaku","h":"#3-improvements-in-interoperability","p":333},{"i":343,"t":"4. Peer discovery","u":"/rlog/introducing-nwaku","h":"#4-peer-discovery","p":333},{"i":345,"t":"DNS-based discovery","u":"/rlog/introducing-nwaku","h":"#dns-based-discovery","p":333},{"i":347,"t":"GossipSub peer exchange","u":"/rlog/introducing-nwaku","h":"#gossipsub-peer-exchange","p":333},{"i":349,"t":"Waku Node Discovery Protocol v5","u":"/rlog/introducing-nwaku","h":"#waku-node-discovery-protocol-v5","p":333},{"i":351,"t":"5. Spam protection using RLN","u":"/rlog/introducing-nwaku","h":"#5-spam-protection-using-rln","p":333},{"i":353,"t":"Future work","u":"/rlog/introducing-nwaku","h":"#future-work","p":333},{"i":355,"t":"Reaching out to operators:","u":"/rlog/introducing-nwaku","h":"#reaching-out-to-operators","p":333},{"i":357,"t":"Better conversational security layer guarantees","u":"/rlog/introducing-nwaku","h":"#better-conversational-security-layer-guarantees","p":333},{"i":359,"t":"Protocol incentivization","u":"/rlog/introducing-nwaku","h":"#protocol-incentivization","p":333},{"i":361,"t":"Improved store capacity","u":"/rlog/introducing-nwaku","h":"#improved-store-capacity","p":333},{"i":363,"t":"Multipurpose discovery","u":"/rlog/introducing-nwaku","h":"#multipurpose-discovery","p":333},{"i":365,"t":"References","u":"/rlog/introducing-nwaku","h":"#references","p":333},{"i":369,"t":"Motivation","u":"/rlog/gsub-largemsg-improvements","h":"#motivation","p":367},{"i":371,"t":"Problem description","u":"/rlog/gsub-largemsg-improvements","h":"#problem-description","p":367},{"i":373,"t":"Possible improvements","u":"/rlog/gsub-largemsg-improvements","h":"#possible-improvements","p":367},{"i":374,"t":"1. Minimizing transfer time for large messages","u":"/rlog/gsub-largemsg-improvements","h":"#1-minimizing-transfer-time-for-large-messages","p":367},{"i":376,"t":"2. Mitigating transport issues","u":"/rlog/gsub-largemsg-improvements","h":"#2-mitigating-transport-issues","p":367},{"i":378,"t":"3. Eliminating redundant transmissions","u":"/rlog/gsub-largemsg-improvements","h":"#3-eliminating-redundant-transmissions","p":367},{"i":380,"t":"4. Message prioritization","u":"/rlog/gsub-largemsg-improvements","h":"#4-message-prioritization","p":367},{"i":382,"t":"5. Maximizing benefits from IWANT messages","u":"/rlog/gsub-largemsg-improvements","h":"#5-maximizing-benefits-from-iwant-messages","p":367},{"i":384,"t":"Summary","u":"/rlog/gsub-largemsg-improvements","h":"#summary","p":367},{"i":386,"t":"References","u":"/rlog/gsub-largemsg-improvements","h":"#references","p":367},{"i":390,"t":"Overview","u":"/rlog/gsub-perf-imp-comparison","h":"#overview","p":388},{"i":392,"t":"Message Transfer Time and Duplicates","u":"/rlog/gsub-perf-imp-comparison","h":"#message-transfer-time-and-duplicates","p":388},{"i":394,"t":"Protocols Considered","u":"/rlog/gsub-perf-imp-comparison","h":"#protocols-considered","p":388},{"i":395,"t":"Push-Pull Phase Transition (PPPT)","u":"/rlog/gsub-perf-imp-comparison","h":"#push-pull-phase-transition-pppt","p":388},{"i":397,"t":"GossipSub v1.4 Proposal","u":"/rlog/gsub-perf-imp-comparison","h":"#gossipsub-v14-proposal","p":388},{"i":399,"t":"GossipSub v2.0 Proposal","u":"/rlog/gsub-perf-imp-comparison","h":"#gossipsub-v20-proposal","p":388},{"i":401,"t":"Experiments","u":"/rlog/gsub-perf-imp-comparison","h":"#experiments","p":388},{"i":403,"t":"Results","u":"/rlog/gsub-perf-imp-comparison","h":"#results","p":388},{"i":405,"t":"Findings","u":"/rlog/gsub-perf-imp-comparison","h":"#findings","p":388},{"i":407,"t":"References","u":"/rlog/gsub-perf-imp-comparison","h":"#references","p":388},{"i":411,"t":"The Beginning","u":"/rlog/kademlia-to-discv5","h":"#the-beginning","p":409},{"i":413,"t":"Distributed Hash Tables","u":"/rlog/kademlia-to-discv5","h":"#distributed-hash-tables","p":409},{"i":415,"t":"Kademlia","u":"/rlog/kademlia-to-discv5","h":"#kademlia","p":409},{"i":417,"t":"Discv4","u":"/rlog/kademlia-to-discv5","h":"#discv4","p":409},{"i":419,"t":"Discv5","u":"/rlog/kademlia-to-discv5","h":"#discv5","p":409},{"i":423,"t":"Introduction","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#introduction","p":421},{"i":425,"t":"Goal 1: Create a State Separation Architecture","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-1-create-a-state-separation-architecture","p":421},{"i":427,"t":"Rationale Behind the Dual Architecture:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-rationale-behind-the-dual-architecture-","p":421},{"i":429,"t":"Harmonizing the Two Systems:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-harmonizing-the-two-systems-","p":421},{"i":431,"t":"Challenges and Solutions","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-challenges-and-solutions-","p":421},{"i":433,"t":"Goal 2: Virtual Machine Creation","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-2-virtual-machine-creation","p":421},{"i":435,"t":"Optimization Concerns for WASM and RISC-V:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-optimization-concerns-for-wasm-and-risc-v-","p":421},{"i":437,"t":"Emerging ZKP Optimized Systems Considerations:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-emerging-zkp-optimized-systems-considerations-","p":421},{"i":439,"t":"Strategies for Integration:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-strategies-for-integration-","p":421},{"i":441,"t":"Goal 3: Proofs Creation and Verification","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-3-proofs-creation-and-verification","p":421},{"i":443,"t":"Goal 4: Kernel-based Architecture Implementation","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-4-kernel-based-architecture-implementation","p":421},{"i":445,"t":"Goal 5: Seamless Interaction Design","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-5-seamless-interaction-design","p":421},{"i":447,"t":"Goal 6: Integration of DeFi Protocols with a Privacy-Preserving Framework","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-6-integration-of-defi-protocols-with-a-privacy-preserving-framework","p":421},{"i":449,"t":"Strategic Roadmap for Goal 6","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-strategic-roadmap-for-goal-6-","p":421},{"i":451,"t":"Summary of the Architecture","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#summary-of-the-architecture","p":421},{"i":453,"t":"Current State","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#current-state","p":421},{"i":455,"t":"References","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"","p":421},{"i":457,"t":"Footnotes","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#footnote-label","p":421},{"i":461,"t":"Nim 2.2 – Better Stability, Smarter Memory, and Smoother Development","u":"/rlog/nim-in-logos-01","h":"#nim-22---better-stability-smarter-memory-and-smoother-development","p":459},{"i":463,"t":"Error Handling in Nim: Why Results Beat Exceptions","u":"/rlog/nim-in-logos-01","h":"#error-handling-in-nim-why-results-beat-exceptions","p":459},{"i":465,"t":"Debugging in Nim","u":"/rlog/nim-in-logos-01","h":"#debugging-in-nim","p":459},{"i":467,"t":"Formatting code in Nim","u":"/rlog/nim-in-logos-01","h":"#formatting-code-in-nim","p":459},{"i":471,"t":"Problem motivation","u":"/rlog/p2p-data-sync-for-mobile","h":"#problem-motivation","p":469},{"i":473,"t":"Why p2p?","u":"/rlog/p2p-data-sync-for-mobile","h":"#why-p2p","p":469},{"i":475,"t":"Why reliably sync data?","u":"/rlog/p2p-data-sync-for-mobile","h":"#why-reliably-sync-data","p":469},{"i":477,"t":"Why mobilephones?","u":"/rlog/p2p-data-sync-for-mobile","h":"#why-mobilephones","p":469},{"i":479,"t":"Minimal Requirements","u":"/rlog/p2p-data-sync-for-mobile","h":"#minimal-requirements","p":469},{"i":481,"t":"MVDS - a minimium viable version","u":"/rlog/p2p-data-sync-for-mobile","h":"#mvds---a-minimium-viable-version","p":469},{"i":483,"t":"Basic simulation","u":"/rlog/p2p-data-sync-for-mobile","h":"#basic-simulation","p":469},{"i":485,"t":"Mostly-offline devices","u":"/rlog/p2p-data-sync-for-mobile","h":"#mostly-offline-devices","p":469},{"i":487,"t":"Basic calculations for bandwidth multiplier","u":"/rlog/p2p-data-sync-for-mobile","h":"#basic-calculations-for-bandwidth-multiplier","p":469},{"i":489,"t":"Future work","u":"/rlog/p2p-data-sync-for-mobile","h":"#future-work","p":469},{"i":492,"t":"zkVM Testing Report: Evaluating Zero-Knowledge Virtual Machines for Nescience","u":"/rlog/page/2","h":"","p":491},{"i":494,"t":"Exploring zkVMs: Which Projects Truly Qualify as Zero-Knowledge Virtual Machines?","u":"/rlog/page/2","h":"","p":491},{"i":496,"t":"Nescience: A User-Centric State-Separation Architecture","u":"/rlog/page/2","h":"","p":491},{"i":498,"t":"Vac 101: Membership with Bloom Filters and Cuckoo Filters","u":"/rlog/page/2","h":"","p":491},{"i":500,"t":"RLN-v3: Towards a Flexible and Cost-Efficient Implementation","u":"/rlog/page/2","h":"","p":491},{"i":502,"t":"Verifying RLN Proofs in Light Clients with Subtrees","u":"/rlog/page/2","h":"","p":491},{"i":504,"t":"Strengthening Anonymous DoS Prevention with Rate Limiting Nullifiers in Waku","u":"/rlog/page/2","h":"","p":491},{"i":506,"t":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","u":"/rlog/page/2","h":"","p":491},{"i":508,"t":"Nescience - A zkVM leveraging hiding properties","u":"/rlog/page/2","h":"","p":491},{"i":510,"t":"Device Pairing in Js-waku and Go-waku","u":"/rlog/page/2","h":"","p":491},{"i":514,"t":"Introduction","u":"/rlog/mdsecheck-method","h":"#introduction","p":512},{"i":516,"t":"MDS matrix: how to define and construct","u":"/rlog/mdsecheck-method","h":"#mds-matrix-how-to-define-and-construct","p":512},{"i":518,"t":"Partial substitution-permutation networks","u":"/rlog/mdsecheck-method","h":"#partial-substitution-permutation-networks","p":512},{"i":520,"t":"Square MDS matrix security check in the context of P-SPNs","u":"/rlog/mdsecheck-method","h":"#square-mds-matrix-security-check-in-the-context-of-p-spns","p":512},{"i":522,"t":"MDSECheck method: getting rid of the matrix powers","u":"/rlog/mdsecheck-method","h":"#mdsecheck-method-getting-rid-of-the-matrix-powers","p":512},{"i":524,"t":"MDSECheck library crate: implementation in Rust","u":"/rlog/mdsecheck-method","h":"#mdsecheck-library-crate-implementation-in-rust","p":512},{"i":526,"t":"Conclusion","u":"/rlog/mdsecheck-method","h":"#conclusion","p":512},{"i":528,"t":"References","u":"/rlog/mdsecheck-method","h":"#references","p":512},{"i":532,"t":"Introducing NSSA: A user-centric approach","u":"/rlog/Nescience-state-separation-architecture","h":"#introducing-nssa-a-user-centric-approach","p":530},{"i":534,"t":"Why NSSA differs from other hybrid execution platforms","u":"/rlog/Nescience-state-separation-architecture","h":"#why-nssa-differs-from-other-hybrid-execution-platforms","p":530},{"i":536,"t":"How Nescience state-separation architecture can be used","u":"/rlog/Nescience-state-separation-architecture","h":"#how-nescience-state-separation-architecture-can-be-used","p":530},{"i":538,"t":"Use case: Adding privacy to existing dapps","u":"/rlog/Nescience-state-separation-architecture","h":"#use-case-adding-privacy-to-existing-dapps","p":530},{"i":540,"t":"Key advantage: Decoupling from the host chain","u":"/rlog/Nescience-state-separation-architecture","h":"#key-advantage-decoupling-from-the-host-chain","p":530},{"i":542,"t":"Conclusion","u":"/rlog/Nescience-state-separation-architecture","h":"#conclusion","p":530},{"i":544,"t":"B. Design","u":"/rlog/Nescience-state-separation-architecture","h":"","p":530},{"i":546,"t":"1. Architecture's components","u":"/rlog/Nescience-state-separation-architecture","h":"#1-architectures-components","p":530},{"i":548,"t":"a) Public state","u":"/rlog/Nescience-state-separation-architecture","h":"#a-public-state","p":530},{"i":550,"t":"b) Private state","u":"/rlog/Nescience-state-separation-architecture","h":"#b-private-state","p":530},{"i":552,"t":"c) ZkVM (zero-knowledge virtual machine)","u":"/rlog/Nescience-state-separation-architecture","h":"#c-zkvm-zero-knowledge-virtual-machine","p":530},{"i":554,"t":"d) Execution types in NSSA","u":"/rlog/Nescience-state-separation-architecture","h":"#d-execution-types-in-nssa","p":530},{"i":556,"t":"e) Nescience users","u":"/rlog/Nescience-state-separation-architecture","h":"#e-nescience-users","p":530},{"i":558,"t":"f) Smart contracts in NSSA","u":"/rlog/Nescience-state-separation-architecture","h":"#f-smart-contracts-in-nssa","p":530},{"i":560,"t":"2. General execution overview","u":"/rlog/Nescience-state-separation-architecture","h":"#2-general-execution-overview","p":530},{"i":562,"t":"User actions","u":"/rlog/Nescience-state-separation-architecture","h":"#user-actions","p":530},{"i":564,"t":"Sequencer actions","u":"/rlog/Nescience-state-separation-architecture","h":"#sequencer-actions","p":530},{"i":566,"t":"3. Execution processes and UTXO management","u":"/rlog/Nescience-state-separation-architecture","h":"#3-execution-processes-and-utxo-management","p":530},{"i":568,"t":"a) Components of a Nescience UTXO","u":"/rlog/Nescience-state-separation-architecture","h":"#a-components-of-a-nescience-utxo","p":530},{"i":570,"t":"b) UTXO lifecycle: From generation to consumption","u":"/rlog/Nescience-state-separation-architecture","h":"#b-utxo-lifecycle-from-generation-to-consumption","p":530},{"i":572,"t":"Summary of UTXO consumption in NSSA","u":"/rlog/Nescience-state-separation-architecture","h":"#summary-of-utxo-consumption-in-nssa","p":530},{"i":574,"t":"C. Cryptographic primitives in NSSA","u":"/rlog/Nescience-state-separation-architecture","h":"","p":530},{"i":576,"t":"a) Hash functions in Nescience","u":"/rlog/Nescience-state-separation-architecture","h":"#a-hash-functions-in-nescience","p":530},{"i":578,"t":"Use case: How to use the Pedersen hash to create the UTXO commitment","u":"/rlog/Nescience-state-separation-architecture","h":"#use-case-how-to-use-the-pedersen-hash-to-create-the-utxo-commitment","p":530},{"i":580,"t":"b) Key management and addresses in Nescience","u":"/rlog/Nescience-state-separation-architecture","h":"#-b-key-management-and-addresses-in-nescience","p":530},{"i":582,"t":"I. Spending key","u":"/rlog/Nescience-state-separation-architecture","h":"#i-spending-key","p":530},{"i":584,"t":"II. Private keys","u":"/rlog/Nescience-state-separation-architecture","h":"#ii-private-keys","p":530},{"i":586,"t":"III. Public keys","u":"/rlog/Nescience-state-separation-architecture","h":"#iii-public-keys","p":530},{"i":588,"t":"IV. Viewing key","u":"/rlog/Nescience-state-separation-architecture","h":"#iv-viewing-key","p":530},{"i":590,"t":"V. Ephemeral key","u":"/rlog/Nescience-state-separation-architecture","h":"#-v-ephemeral-key","p":530},{"i":592,"t":"VI. Nescience addresses","u":"/rlog/Nescience-state-separation-architecture","h":"#vi-nescience-addresses","p":530},{"i":594,"t":"VII. Conclusion","u":"/rlog/Nescience-state-separation-architecture","h":"#vii-conclusion","p":530},{"i":596,"t":"c) Trees in NSSA","u":"/rlog/Nescience-state-separation-architecture","h":"#c-trees-in-nssa","p":530},{"i":598,"t":"e) Recursive-friendly privacy-preserving zk-zkVM","u":"/rlog/Nescience-state-separation-architecture","h":"#e-recursive-friendly-privacy-preserving-zk-zkvm","p":530},{"i":600,"t":"f) MPC-based synchronization mechanism (under review)","u":"/rlog/Nescience-state-separation-architecture","h":"#f-mpc-based-synchronization-mechanism-under-review","p":530},{"i":602,"t":"D. Future plans for Nescience","u":"/rlog/Nescience-state-separation-architecture","h":"","p":530},{"i":604,"t":"References","u":"/rlog/Nescience-state-separation-architecture","h":"","p":530},{"i":607,"t":"Presenting JS-Waku: Waku v2 in the Browser","u":"/rlog/page/4","h":"","p":606},{"i":609,"t":"Privacy-preserving p2p economic spam protection in Waku v2","u":"/rlog/page/4","h":"","p":606},{"i":611,"t":"[Talk] Vac, Waku v2 and Ethereum Messaging","u":"/rlog/page/4","h":"","p":606},{"i":613,"t":"Waku v2 Update","u":"/rlog/page/4","h":"","p":606},{"i":615,"t":"What's the Plan for Waku v2?","u":"/rlog/page/4","h":"","p":606},{"i":617,"t":"Feasibility Study: Discv5","u":"/rlog/page/4","h":"","p":606},{"i":619,"t":"What Would a WeChat Replacement Need?","u":"/rlog/page/4","h":"","p":606},{"i":621,"t":"From Kademlia to Discv5","u":"/rlog/page/4","h":"","p":606},{"i":623,"t":"Waku Update","u":"/rlog/page/4","h":"","p":606},{"i":625,"t":"DNS Based Discovery","u":"/rlog/page/4","h":"","p":606},{"i":628,"t":"The Future of Waku Network: Scaling, Incentivization, and Heterogeneity","u":"/rlog/page/3","h":"","p":627},{"i":630,"t":"Waku for All Decentralized Applications and Infrastructures","u":"/rlog/page/3","h":"","p":627},{"i":632,"t":"Building Privacy-Protecting Infrastructure","u":"/rlog/page/3","h":"","p":627},{"i":634,"t":"Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay","u":"/rlog/page/3","h":"","p":627},{"i":636,"t":"Noise handshakes as key-exchange mechanism for Waku","u":"/rlog/page/3","h":"","p":627},{"i":638,"t":"Waku v2 Ambient Peer Discovery","u":"/rlog/page/3","h":"","p":627},{"i":640,"t":"Introducing nwaku","u":"/rlog/page/3","h":"","p":627},{"i":642,"t":"Opinion: Pseudo-ethics in the Surveillance Tech Industry","u":"/rlog/page/3","h":"","p":627},{"i":644,"t":"Waku v1 vs Waku v2: Bandwidth Comparison","u":"/rlog/page/3","h":"","p":627},{"i":646,"t":"[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging","u":"/rlog/page/3","h":"","p":627},{"i":649,"t":"Fixing Whisper with Waku","u":"/rlog/page/5","h":"","p":648},{"i":651,"t":"Feasibility Study: Semaphore rate limiting through zkSNARKs","u":"/rlog/page/5","h":"","p":648},{"i":653,"t":"P2P Data Sync with a Remote Log","u":"/rlog/page/5","h":"","p":648},{"i":655,"t":"Vac - A Rough Overview","u":"/rlog/page/5","h":"","p":648},{"i":657,"t":"P2P Data Sync for Mobile","u":"/rlog/page/5","h":"","p":648},{"i":661,"t":"Waku v2","u":"/rlog/presenting-js-waku","h":"#waku-v2","p":659},{"i":663,"t":"Waku v2 in the browser","u":"/rlog/presenting-js-waku","h":"#waku-v2-in-the-browser","p":659},{"i":665,"t":"Achievements so far","u":"/rlog/presenting-js-waku","h":"#achievements-so-far","p":659},{"i":667,"t":"What's next?","u":"/rlog/presenting-js-waku","h":"#whats-next","p":659},{"i":671,"t":"Remote log","u":"/rlog/remote-log","h":"#remote-log","p":669},{"i":673,"t":"Definitions","u":"/rlog/remote-log","h":"#definitions","p":669},{"i":675,"t":"Roles","u":"/rlog/remote-log","h":"#roles","p":669},{"i":677,"t":"Flow","u":"/rlog/remote-log","h":"#flow","p":669},{"i":678,"t":"Data format","u":"/rlog/remote-log","h":"#data-format","p":669},{"i":680,"t":"Interaction with MVDS","u":"/rlog/remote-log","h":"#interaction-with-mvds","p":669},{"i":682,"t":"Future work","u":"/rlog/remote-log","h":"#future-work","p":669},{"i":686,"t":"Introduction","u":"/rlog/rln-light-verifiers","h":"#introduction","p":684},{"i":688,"t":"Constraints and requirements","u":"/rlog/rln-light-verifiers","h":"#constraints-and-requirements","p":684},{"i":690,"t":"Metrics on sync time for a tree with 2,653 leaves","u":"/rlog/rln-light-verifiers","h":"#metrics-on-sync-time-for-a-tree-with-2653-leaves","p":684},{"i":692,"t":"Test bench","u":"/rlog/rln-light-verifiers","h":"#test-bench","p":684},{"i":694,"t":"Metrics","u":"/rlog/rln-light-verifiers","h":"#metrics","p":684},{"i":696,"t":"Proposed solution","u":"/rlog/rln-light-verifiers","h":"#proposed-solution","p":684},{"i":698,"t":"Insertion","u":"/rlog/rln-light-verifiers","h":"#insertion","p":684},{"i":700,"t":"Syncing","u":"/rlog/rln-light-verifiers","h":"#syncing","p":684},{"i":702,"t":"Gas costs","u":"/rlog/rln-light-verifiers","h":"#gas-costs","p":684},{"i":704,"t":"Events","u":"/rlog/rln-light-verifiers","h":"#events","p":684},{"i":706,"t":"Proof of concept","u":"/rlog/rln-light-verifiers","h":"#proof-of-concept","p":684},{"i":708,"t":"Future work","u":"/rlog/rln-light-verifiers","h":"#future-work","p":684},{"i":710,"t":"Conclusion","u":"/rlog/rln-light-verifiers","h":"#conclusion","p":684},{"i":712,"t":"References","u":"/rlog/rln-light-verifiers","h":"#references","p":684},{"i":716,"t":"Introduction","u":"/rlog/rln-anonymous-dos-prevention","h":"#introduction","p":714},{"i":718,"t":"RLN Protocol parameters","u":"/rlog/rln-anonymous-dos-prevention","h":"#rln-protocol-parameters","p":714},{"i":720,"t":"Malicious User secret interpolation mechanism","u":"/rlog/rln-anonymous-dos-prevention","h":"#malicious-user-secret-interpolation-mechanism","p":714},{"i":722,"t":"Waku's problem with DoS","u":"/rlog/rln-anonymous-dos-prevention","h":"#wakus-problem-with-dos","p":714},{"i":724,"t":"DoS prevention with user metadata","u":"/rlog/rln-anonymous-dos-prevention","h":"#dos-prevention-with-user-metadata","p":714},{"i":726,"t":"Performance analysis","u":"/rlog/rln-anonymous-dos-prevention","h":"#performance-analysis","p":714},{"i":728,"t":"Security analysis","u":"/rlog/rln-anonymous-dos-prevention","h":"#security-analysis","p":714},{"i":730,"t":"Storage analysis","u":"/rlog/rln-anonymous-dos-prevention","h":"#storage-analysis","p":714},{"i":732,"t":"The bare minimum requirements to run RLN","u":"/rlog/rln-anonymous-dos-prevention","h":"#the-bare-minimum-requirements-to-run-rln","p":714},{"i":734,"t":"RLN usage guide","u":"/rlog/rln-anonymous-dos-prevention","h":"#rln-usage-guide","p":714},{"i":736,"t":"Future work","u":"/rlog/rln-anonymous-dos-prevention","h":"#future-work","p":714},{"i":738,"t":"References","u":"/rlog/rln-anonymous-dos-prevention","h":"#references","p":714},{"i":742,"t":"Basic terms","u":"/rlog/vac-overview","h":"#basic-terms","p":740},{"i":744,"t":"Protocol stack","u":"/rlog/vac-overview","h":"#protocol-stack","p":740},{"i":746,"t":"Problems and rough priorities","u":"/rlog/vac-overview","h":"#problems-and-rough-priorities","p":740},{"i":750,"t":"Introduction","u":"/rlog/rln-relay","h":"#introduction","p":748},{"i":752,"t":"What do we mean by spamming?","u":"/rlog/rln-relay","h":"#what-do-we-mean-by-spamming","p":748},{"i":754,"t":"Possible Solutions","u":"/rlog/rln-relay","h":"#possible-solutions","p":748},{"i":756,"t":"Centralized Messaging Systems","u":"/rlog/rln-relay","h":"#centralized-messaging-systems","p":748},{"i":758,"t":"P2P Systems","u":"/rlog/rln-relay","h":"#p2p-systems","p":748},{"i":760,"t":"Technical Terms","u":"/rlog/rln-relay","h":"#technical-terms","p":748},{"i":762,"t":"Overview: Economic-Incentive Spam protection through Rate Limiting Nullifiers","u":"/rlog/rln-relay","h":"#overview-economic-incentive-spam-protection-through-rate-limiting-nullifiers","p":748},{"i":764,"t":"Flow","u":"/rlog/rln-relay","h":"#flow","p":748},{"i":766,"t":"Setup and Registration","u":"/rlog/rln-relay","h":"#setup-and-registration","p":748},{"i":768,"t":"Maintaining the membership Merkle Tree","u":"/rlog/rln-relay","h":"#maintaining-the-membership-merkle-tree","p":748},{"i":770,"t":"Publishing","u":"/rlog/rln-relay","h":"#publishing","p":748},{"i":772,"t":"Routing","u":"/rlog/rln-relay","h":"#routing","p":748},{"i":774,"t":"Spam Detection and Slashing","u":"/rlog/rln-relay","h":"#spam-detection-and-slashing","p":748},{"i":776,"t":"Feasibility and Open Issues","u":"/rlog/rln-relay","h":"#feasibility-and-open-issues","p":748},{"i":778,"t":"Storage overhead per peer","u":"/rlog/rln-relay","h":"#storage-overhead-per-peer","p":748},{"i":780,"t":"Cost-effective way of member insertion and deletion","u":"/rlog/rln-relay","h":"#cost-effective-way-of-member-insertion-and-deletion","p":748},{"i":782,"t":"Exceeding the messaging rate via multiple registrations","u":"/rlog/rln-relay","h":"#exceeding-the-messaging-rate-via-multiple-registrations","p":748},{"i":784,"t":"Conclusion and Future Steps","u":"/rlog/rln-relay","h":"#conclusion-and-future-steps","p":748},{"i":786,"t":"Acknowledgement","u":"/rlog/rln-relay","h":"#acknowledgement","p":748},{"i":788,"t":"References","u":"/rlog/rln-relay","h":"#references","p":748},{"i":790,"t":"Footnotes","u":"/rlog/rln-relay","h":"#footnote-label","p":748},{"i":794,"t":"Introduction","u":"/rlog/rln-v3","h":"#introduction","p":792},{"i":796,"t":"Theory","u":"/rlog/rln-v3","h":"#theory","p":792},{"i":797,"t":"Modification to leaves set in the membership Merkle tree","u":"/rlog/rln-v3","h":"#modification-to-leaves-set-in-the-membership-merkle-tree","p":792},{"i":799,"t":"Modification to circuit inputs","u":"/rlog/rln-v3","h":"#modification-to-circuit-inputs","p":792},{"i":801,"t":"Additional circuit constraints","u":"/rlog/rln-v3","h":"#additional-circuit-constraints","p":792},{"i":803,"t":"Modifications to external epoch validation (Waku, etc.)","u":"/rlog/rln-v3","h":"#modifications-to-external-epoch-validation-waku-etc","p":792},{"i":805,"t":"Modifications to double signaling detection scheme (Waku, etc.)","u":"/rlog/rln-v3","h":"#modifications-to-double-signaling-detection-scheme-waku-etc","p":792},{"i":807,"t":"The implementation","u":"/rlog/rln-v3","h":"#the-implementation","p":792},{"i":809,"t":"Comments on performance","u":"/rlog/rln-v3","h":"#comments-on-performance","p":792},{"i":811,"t":"Proving","u":"/rlog/rln-v3","h":"#proving","p":792},{"i":813,"t":"Verification","u":"/rlog/rln-v3","h":"#verification","p":792},{"i":815,"t":"Conclusion","u":"/rlog/rln-v3","h":"#conclusion","p":792},{"i":817,"t":"Future work","u":"/rlog/rln-v3","h":"#future-work","p":792},{"i":819,"t":"References","u":"/rlog/rln-v3","h":"#references","p":792},{"i":823,"t":"Background","u":"/rlog/waku-for-all","h":"#background","p":821},{"i":826,"t":"Waku for Your Project","u":"/rlog/waku-for-all","h":"#waku-for-your-project","p":821},{"i":828,"t":"Layer-2 Decentralization","u":"/rlog/waku-for-all","h":"#layer-2-decentralization","p":821},{"i":830,"t":"Device pairing and communication","u":"/rlog/waku-for-all","h":"#device-pairing-and-communication","p":821},{"i":832,"t":"Get Involved","u":"/rlog/waku-for-all","h":"#get-involved","p":821},{"i":834,"t":"Moving Forward","u":"/rlog/waku-for-all","h":"#moving-forward","p":821},{"i":836,"t":"References","u":"/rlog/waku-for-all","h":"#references","p":821},{"i":840,"t":"Current state","u":"/rlog/waku-update","h":"#current-state","p":838},{"i":842,"t":"How many users does Waku support?","u":"/rlog/waku-update","h":"#how-many-users-does-waku-support","p":838},{"i":844,"t":"Simulation","u":"/rlog/waku-update","h":"#simulation","p":838},{"i":846,"t":"Difference between Waku and Whisper","u":"/rlog/waku-update","h":"#difference-between-waku-and-whisper","p":838},{"i":848,"t":"Next steps and future plans","u":"/rlog/waku-update","h":"#next-steps-and-future-plans","p":838},{"i":850,"t":"Acknowledgements","u":"/rlog/waku-update","h":"#acknowledgements","p":838},{"i":854,"t":"Membership with Bloom Filters and Cuckoo Filters","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#membership-with-bloom-filters-and-cuckoo-filters","p":852},{"i":856,"t":"Bloom filters","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#bloom-filters","p":852},{"i":858,"t":"Complexity","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#complexity","p":852},{"i":860,"t":"Example","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#example","p":852},{"i":862,"t":"Probability of false positives","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#probability-of-false-positives","p":852},{"i":864,"t":"Sliding-Window Bloom filter","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#sliding-window-bloom-filter","p":852},{"i":866,"t":"Cuckoo filters","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#cuckoo-filters","p":852},{"i":868,"t":"Example","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#example-1","p":852},{"i":870,"t":"Complexity","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#complexity-1","p":852},{"i":872,"t":"Bloom filters vs Cuckoo filters","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#bloom-filters-vs-cuckoo-filters","p":852},{"i":874,"t":"Combining Filters with RLN","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#combining-filters-with-rln","p":852},{"i":876,"t":"References","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","h":"#references","p":852},{"i":880,"t":"Introduction","u":"/rlog/vac101-fiat-shamir","h":"#introduction","p":878},{"i":882,"t":"Sigma Protocols","u":"/rlog/vac101-fiat-shamir","h":"#sigma-protocols","p":878},{"i":884,"t":"The Schnorr Protocol","u":"/rlog/vac101-fiat-shamir","h":"#the-schnorr-protocol","p":878},{"i":886,"t":"Chaum-Pedersen protocol","u":"/rlog/vac101-fiat-shamir","h":"#chaum-pedersen-protocol","p":878},{"i":888,"t":"Hash Functions","u":"/rlog/vac101-fiat-shamir","h":"#hash-functions","p":878},{"i":890,"t":"The Fiat-Shamir heuristic","u":"/rlog/vac101-fiat-shamir","h":"#the-fiat-shamir-heuristic","p":878},{"i":892,"t":"Schnorr Protocol with the strong Fiat-Shamir","u":"/rlog/vac101-fiat-shamir","h":"#schnorr-protocol-with-the-strong-fiat-shamir","p":878},{"i":894,"t":"Chaum-Pedersen Protocol with the strong Fiat-Shamir","u":"/rlog/vac101-fiat-shamir","h":"#chaum-pedersen-protocol-with-the-strong-fiat-shamir","p":878},{"i":896,"t":"Improper use of the Fiat-Shamir heuristic","u":"/rlog/vac101-fiat-shamir","h":"#improper-use-of-the-fiat-shamir-heuristic","p":878},{"i":898,"t":"Schnorr protocol with the weak Fiat-Shamir heuristic","u":"/rlog/vac101-fiat-shamir","h":"#schnorr-protocol-with-the-weak-fiat-shamir-heuristic","p":878},{"i":900,"t":"Chaum-Pedersen protocol with the Fiat-Shamir heuristic","u":"/rlog/vac101-fiat-shamir","h":"#chaum-pedersen-protocol-with-the-fiat-shamir-heuristic","p":878},{"i":902,"t":"Conclusion","u":"/rlog/vac101-fiat-shamir","h":"#conclusion","p":878},{"i":904,"t":"References","u":"/rlog/vac101-fiat-shamir","h":"#references","p":878},{"i":908,"t":"Introduction","u":"/rlog/waku-v2-ethereum-coscup","h":"#introduction","p":906},{"i":910,"t":"Brief history and background","u":"/rlog/waku-v2-ethereum-coscup","h":"#brief-history-and-background","p":906},{"i":912,"t":"Waku v2","u":"/rlog/waku-v2-ethereum-coscup","h":"#waku-v2","p":906},{"i":913,"t":"Overview","u":"/rlog/waku-v2-ethereum-coscup","h":"#overview","p":906},{"i":915,"t":"Goals","u":"/rlog/waku-v2-ethereum-coscup","h":"#goals","p":906},{"i":917,"t":"Protocols","u":"/rlog/waku-v2-ethereum-coscup","h":"#protocols","p":906},{"i":919,"t":"Implementations","u":"/rlog/waku-v2-ethereum-coscup","h":"#implementations","p":906},{"i":921,"t":"Testnet Huilong and dogfooding","u":"/rlog/waku-v2-ethereum-coscup","h":"#testnet-huilong-and-dogfooding","p":906},{"i":923,"t":"Research","u":"/rlog/waku-v2-ethereum-coscup","h":"#research","p":906},{"i":925,"t":"Use cases","u":"/rlog/waku-v2-ethereum-coscup","h":"#use-cases","p":906},{"i":927,"t":"Prelude: Topics in Waku v2","u":"/rlog/waku-v2-ethereum-coscup","h":"#prelude-topics-in-waku-v2","p":906},{"i":929,"t":"Status app","u":"/rlog/waku-v2-ethereum-coscup","h":"#status-app","p":906},{"i":931,"t":"DappConnect: Ethereum messaging","u":"/rlog/waku-v2-ethereum-coscup","h":"#dappconnect-ethereum-messaging","p":906},{"i":933,"t":"WalletConnect v2","u":"/rlog/waku-v2-ethereum-coscup","h":"#walletconnect-v2","p":906},{"i":935,"t":"More examples","u":"/rlog/waku-v2-ethereum-coscup","h":"#more-examples","p":906},{"i":937,"t":"Contribute","u":"/rlog/waku-v2-ethereum-coscup","h":"#contribute","p":906},{"i":939,"t":"Conclusion","u":"/rlog/waku-v2-ethereum-coscup","h":"#conclusion","p":906},{"i":943,"t":"Background","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#background","p":941},{"i":945,"t":"Theoretical improvements in Waku v2","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#theoretical-improvements-in-waku-v2","p":941},{"i":947,"t":"Methodology","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#methodology","p":941},{"i":949,"t":"Network size comparison","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#network-size-comparison","p":941},{"i":950,"t":"Iteration 1: 10 nodes","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#iteration-1-10-nodes","p":941},{"i":952,"t":"Iteration 2: 30 nodes","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#iteration-2-30-nodes","p":941},{"i":954,"t":"Iteration 3: 50 nodes","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#iteration-3-50-nodes","p":941},{"i":956,"t":"Iteration 4: 85 nodes","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#iteration-4-85-nodes","p":941},{"i":958,"t":"Iteration 5: 150 nodes","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#iteration-5-150-nodes","p":941},{"i":960,"t":"Discussion","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#discussion","p":941},{"i":962,"t":"Network traffic comparison","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#network-traffic-comparison","p":941},{"i":964,"t":"Conclusions","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#conclusions","p":941},{"i":966,"t":"Future work","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#future-work","p":941},{"i":968,"t":"References","u":"/rlog/waku-v1-v2-bandwidth-comparison","h":"#references","p":941},{"i":972,"t":"0. Introduction","u":"/rlog/waku-v2-ethereum-messaging","h":"#0-introduction","p":970},{"i":974,"t":"PART 1 - VAC AND THE JOURNEY FROM WHISPER TO WAKU V1 TO WAKU V2","u":"/rlog/waku-v2-ethereum-messaging","h":"#part-1---vac-and-the-journey-from-whisper-to-waku-v1-to-waku-v2","p":970},{"i":975,"t":"1. Vac intro","u":"/rlog/waku-v2-ethereum-messaging","h":"#1-vac-intro","p":970},{"i":977,"t":"2. Whisper to Waku v1","u":"/rlog/waku-v2-ethereum-messaging","h":"#2-whisper-to-waku-v1","p":970},{"i":979,"t":"3. Waku v1 to v2","u":"/rlog/waku-v2-ethereum-messaging","h":"#3-waku-v1-to-v2","p":970},{"i":981,"t":"3.5 Waku v2 - Design goals","u":"/rlog/waku-v2-ethereum-messaging","h":"#35-waku-v2---design-goals","p":970},{"i":983,"t":"4. Waku v2 - Breakdown","u":"/rlog/waku-v2-ethereum-messaging","h":"#4-waku-v2---breakdown","p":970},{"i":985,"t":"5. Waku v2 - Upcoming","u":"/rlog/waku-v2-ethereum-messaging","h":"#5-waku-v2---upcoming","p":970},{"i":987,"t":"PART 2 - ETHEREUM MESSAGING","u":"/rlog/waku-v2-ethereum-messaging","h":"#part-2---ethereum-messaging","p":970},{"i":989,"t":"6. Ethereum Messaging - Why?","u":"/rlog/waku-v2-ethereum-messaging","h":"#6-ethereum-messaging---why","p":970},{"i":991,"t":"7. Ethereum Messaging - Why? (Cont)","u":"/rlog/waku-v2-ethereum-messaging","h":"#7-ethereum-messaging---why-cont","p":970},{"i":993,"t":"8. What's needed to deliver this?","u":"/rlog/waku-v2-ethereum-messaging","h":"#8-whats-needed-to-deliver-this","p":970},{"i":995,"t":"9. Breaking up the problem and a high level roadmap","u":"/rlog/waku-v2-ethereum-messaging","h":"#9-breaking-up-the-problem-and-a-high-level-roadmap","p":970},{"i":997,"t":"10. We are hiring!","u":"/rlog/waku-v2-ethereum-messaging","h":"#10-we-are-hiring","p":970},{"i":1001,"t":"Problem","u":"/rlog/waku-v2-plan","h":"#problem","p":999},{"i":1003,"t":"Appetite","u":"/rlog/waku-v2-plan","h":"#appetite","p":999},{"i":1005,"t":"Solution","u":"/rlog/waku-v2-plan","h":"#solution","p":999},{"i":1007,"t":"Baseline","u":"/rlog/waku-v2-plan","h":"#baseline","p":999},{"i":1009,"t":"Track 1 - Move to libp2p","u":"/rlog/waku-v2-plan","h":"#track-1---move-to-libp2p","p":999},{"i":1011,"t":"1. FloodSub","u":"/rlog/waku-v2-plan","h":"#1-floodsub","p":999},{"i":1013,"t":"2. Simplify the protocol","u":"/rlog/waku-v2-plan","h":"#2-simplify-the-protocol","p":999},{"i":1015,"t":"3. Core integration","u":"/rlog/waku-v2-plan","h":"#3-core-integration","p":999},{"i":1017,"t":"4. Topic interest behavior","u":"/rlog/waku-v2-plan","h":"#4-topic-interest-behavior","p":999},{"i":1019,"t":"5. Historical message caching","u":"/rlog/waku-v2-plan","h":"#5-historical-message-caching","p":999},{"i":1021,"t":"6. Waku v1 <\\> Libp2p bridge","u":"/rlog/waku-v2-plan","h":"#6-waku-v1--libp2p-bridge","p":999},{"i":1023,"t":"Track 2 - Better routing","u":"/rlog/waku-v2-plan","h":"#track-2---better-routing","p":999},{"i":1025,"t":"1. GossipSub","u":"/rlog/waku-v2-plan","h":"#1-gossipsub","p":999},{"i":1027,"t":"2. Topic sharding","u":"/rlog/waku-v2-plan","h":"#2-topic-sharding","p":999},{"i":1029,"t":"3. Other factors","u":"/rlog/waku-v2-plan","h":"#3-other-factors","p":999},{"i":1031,"t":"Track 3 - Accounting and user-run nodes","u":"/rlog/waku-v2-plan","h":"#track-3---accounting-and-user-run-nodes","p":999},{"i":1033,"t":"1. Adaptive nodes and capabilities","u":"/rlog/waku-v2-plan","h":"#1-adaptive-nodes-and-capabilities","p":999},{"i":1035,"t":"2. Accounting","u":"/rlog/waku-v2-plan","h":"#2-accounting","p":999},{"i":1037,"t":"3. Relax high availability requirement","u":"/rlog/waku-v2-plan","h":"#3-relax-high-availability-requirement","p":999},{"i":1039,"t":"4. Incentivize light and full nodes to tell the truth (policy, etc)","u":"/rlog/waku-v2-plan","h":"#4-incentivize-light-and-full-nodes-to-tell-the-truth-policy-etc","p":999},{"i":1041,"t":"5. Settlement PoC","u":"/rlog/waku-v2-plan","h":"#5-settlement-poc","p":999},{"i":1043,"t":"Out of scope","u":"/rlog/waku-v2-plan","h":"#out-of-scope","p":999},{"i":1047,"t":"Recap","u":"/rlog/waku-v2-update","h":"#recap","p":1045},{"i":1049,"t":"Current state","u":"/rlog/waku-v2-update","h":"#current-state","p":1045},{"i":1051,"t":"Specs","u":"/rlog/waku-v2-update","h":"#specs","p":1045},{"i":1053,"t":"Implementation","u":"/rlog/waku-v2-update","h":"#implementation","p":1045},{"i":1055,"t":"Nangang testnet","u":"/rlog/waku-v2-update","h":"#nangang-testnet","p":1045},{"i":1057,"t":"Waku Web PoC","u":"/rlog/waku-v2-update","h":"#waku-web-poc","p":1045},{"i":1059,"t":"Coming up","u":"/rlog/waku-v2-update","h":"#coming-up","p":1045},{"i":1061,"t":"Things that are missing","u":"/rlog/waku-v2-update","h":"#things-that-are-missing","p":1045},{"i":1063,"t":"Upcoming","u":"/rlog/waku-v2-update","h":"#upcoming","p":1045},{"i":1067,"t":"Static Node Lists","u":"/rlog/wakuv2-apd","h":"#static-node-lists","p":1065},{"i":1069,"t":"DNS-based Discovery","u":"/rlog/wakuv2-apd","h":"#dns-based-discovery","p":1065},{"i":1071,"t":"Discovery V5","u":"/rlog/wakuv2-apd","h":"#discovery-v5","p":1065},{"i":1073,"t":"DHT Background","u":"/rlog/wakuv2-apd","h":"#dht-background","p":1065},{"i":1075,"t":"Random Walk Discovery","u":"/rlog/wakuv2-apd","h":"#random-walk-discovery","p":1065},{"i":1077,"t":"Random Walk Performance Estimation","u":"/rlog/wakuv2-apd","h":"#random-walk-performance-estimation","p":1065},{"i":1079,"t":"Simple Solution: Separate Discovery Network","u":"/rlog/wakuv2-apd","h":"#simple-solution-separate-discovery-network","p":1065},{"i":1081,"t":"Discv5 Topic Discovery","u":"/rlog/wakuv2-apd","h":"#discv5-topic-discovery","p":1065},{"i":1083,"t":"Attacks on DHTs","u":"/rlog/wakuv2-apd","h":"#attacks-on-dhts","p":1065},{"i":1085,"t":"Peer Exchange Protocol","u":"/rlog/wakuv2-apd","h":"#peer-exchange-protocol","p":1065},{"i":1087,"t":"Further Protocols Related to Discovery","u":"/rlog/wakuv2-apd","h":"#further-protocols-related-to-discovery","p":1065},{"i":1089,"t":"Gossipsub Peer Exchange Protocol","u":"/rlog/wakuv2-apd","h":"#gossipsub-peer-exchange-protocol","p":1065},{"i":1091,"t":"Capability Negotiation","u":"/rlog/wakuv2-apd","h":"#capability-negotiation","p":1065},{"i":1093,"t":"NAT traversal","u":"/rlog/wakuv2-apd","h":"#nat-traversal","p":1065},{"i":1095,"t":"Conclusion and Future Prospects","u":"/rlog/wakuv2-apd","h":"#conclusion-and-future-prospects","p":1065},{"i":1097,"t":"References","u":"/rlog/wakuv2-apd","h":"#references","p":1065},{"i":1101,"t":"Introduction","u":"/rlog/wakuv2-noise","h":"#introduction","p":1099},{"i":1103,"t":"The Diffie-Hellman Key-exchange","u":"/rlog/wakuv2-noise","h":"#the-diffie-hellman-key-exchange","p":1099},{"i":1105,"t":"Ephemeral and Static Public Keys","u":"/rlog/wakuv2-noise","h":"#ephemeral-and-static-public-keys","p":1099},{"i":1107,"t":"The Noise Protocol Framework","u":"/rlog/wakuv2-noise","h":"#the-noise-protocol-framework","p":1099},{"i":1109,"t":"Message patterns","u":"/rlog/wakuv2-noise","h":"#message-patterns","p":1099},{"i":1111,"t":"The Noise State Objects","u":"/rlog/wakuv2-noise","h":"#the-noise-state-objects","p":1099},{"i":1113,"t":"Supported Noise Handshakes in Waku","u":"/rlog/wakuv2-noise","h":"#supported-noise-handshakes-in-waku","p":1099},{"i":1115,"t":"The K1K1 Handshake","u":"/rlog/wakuv2-noise","h":"#the-k1k1-handshake","p":1099},{"i":1117,"t":"The XK1 Handshake","u":"/rlog/wakuv2-noise","h":"#the-xk1-handshake","p":1099},{"i":1119,"t":"The XX and XXpsk0 Handshakes","u":"/rlog/wakuv2-noise","h":"#the-xx-and-xxpsk0-handshakes","p":1099},{"i":1121,"t":"Session Management and Multi-Device Support","u":"/rlog/wakuv2-noise","h":"#session-management-and-multi-device-support","p":1099},{"i":1123,"t":"Conclusions","u":"/rlog/wakuv2-noise","h":"#conclusions","p":1099},{"i":1125,"t":"Future steps","u":"/rlog/wakuv2-noise","h":"#future-steps","p":1099},{"i":1127,"t":"References","u":"/rlog/wakuv2-noise","h":"#references","p":1099},{"i":1131,"t":"Background","u":"/rlog/wechat-replacement-need","h":"#background","p":1129},{"i":1132,"t":"What WeChat provides to the end-user","u":"/rlog/wechat-replacement-need","h":"#what-wechat-provides-to-the-end-user","p":1129},{"i":1134,"t":"How WeChat works - a toy model","u":"/rlog/wechat-replacement-need","h":"#how-wechat-works---a-toy-model","p":1129},{"i":1136,"t":"What do we want?","u":"/rlog/wechat-replacement-need","h":"#what-do-we-want","p":1129},{"i":1138,"t":"Counterpoint 1","u":"/rlog/wechat-replacement-need","h":"#counterpoint-1","p":1129},{"i":1140,"t":"Counterpoint 2","u":"/rlog/wechat-replacement-need","h":"#counterpoint-2","p":1129},{"i":1142,"t":"Principal components","u":"/rlog/wechat-replacement-need","h":"#principal-components","p":1129},{"i":1144,"t":"Background: Ethereum and Web3 stack","u":"/rlog/wechat-replacement-need","h":"#background-ethereum-and-web3-stack","p":1129},{"i":1146,"t":"Account - self-sovereign identity and the perils of phone numbers","u":"/rlog/wechat-replacement-need","h":"#account---self-sovereign-identity-and-the-perils-of-phone-numbers","p":1129},{"i":1148,"t":"Routing - packets from A to B","u":"/rlog/wechat-replacement-need","h":"#routing---packets-from-a-to-b","p":1129},{"i":1150,"t":"Storage - available and persistant for later","u":"/rlog/wechat-replacement-need","h":"#storage---available-and-persistant-for-later","p":1129},{"i":1152,"t":"Messaging - from me to you to all of us (not them)","u":"/rlog/wechat-replacement-need","h":"#messaging---from-me-to-you-to-all-of-us-not-them","p":1129},{"i":1154,"t":"Compute - transact, contract and settle","u":"/rlog/wechat-replacement-need","h":"#compute---transact-contract-and-settle","p":1129},{"i":1156,"t":"Secure chat - just our business","u":"/rlog/wechat-replacement-need","h":"#secure-chat---just-our-business","p":1129},{"i":1158,"t":"Extensible mini apps","u":"/rlog/wechat-replacement-need","h":"#extensible-mini-apps","p":1129},{"i":1160,"t":"Where are we now?","u":"/rlog/wechat-replacement-need","h":"#where-are-we-now","p":1129},{"i":1162,"t":"What's next?","u":"/rlog/wechat-replacement-need","h":"#whats-next","p":1129},{"i":1164,"t":"Acknowledgements","u":"/rlog/wechat-replacement-need","h":"#acknowledgements","p":1129},{"i":1166,"t":"References","u":"/rlog/wechat-replacement-need","h":"#references","p":1129},{"i":1168,"t":"Footnotes","u":"/rlog/wechat-replacement-need","h":"#footnote-label","p":1129},{"i":1172,"t":"Informal Definitions: Security, Privacy, and Anonymity","u":"/rlog/wakuv2-relay-anon","h":"#informal-definitions-security-privacy-and-anonymity","p":1170},{"i":1174,"t":"Security","u":"/rlog/wakuv2-relay-anon","h":"#security","p":1170},{"i":1176,"t":"Privacy","u":"/rlog/wakuv2-relay-anon","h":"#privacy","p":1170},{"i":1178,"t":"Anonymity","u":"/rlog/wakuv2-relay-anon","h":"#anonymity","p":1170},{"i":1180,"t":"Anonymity Trilemma","u":"/rlog/wakuv2-relay-anon","h":"#anonymity-trilemma","p":1170},{"i":1182,"t":"Censorship Resistance","u":"/rlog/wakuv2-relay-anon","h":"#censorship-resistance","p":1170},{"i":1184,"t":"Attacker Types","u":"/rlog/wakuv2-relay-anon","h":"#attacker-types","p":1170},{"i":1186,"t":"Internal","u":"/rlog/wakuv2-relay-anon","h":"#internal","p":1170},{"i":1188,"t":"External","u":"/rlog/wakuv2-relay-anon","h":"#external","p":1170},{"i":1190,"t":"Attack-based Threat Analysis","u":"/rlog/wakuv2-relay-anon","h":"#attack-based-threat-analysis","p":1170},{"i":1192,"t":"Scope","u":"/rlog/wakuv2-relay-anon","h":"#scope","p":1170},{"i":1194,"t":"Prerequisite: Get a Specific Position in the Network","u":"/rlog/wakuv2-relay-anon","h":"#prerequisite-get-a-specific-position-in-the-network","p":1170},{"i":1196,"t":"Replay Attack","u":"/rlog/wakuv2-relay-anon","h":"#replay-attack","p":1170},{"i":1198,"t":"Neighbourhood Surveillance","u":"/rlog/wakuv2-relay-anon","h":"#neighbourhood-surveillance","p":1170},{"i":1200,"t":"Controlled Neighbourhood","u":"/rlog/wakuv2-relay-anon","h":"#controlled-neighbourhood","p":1170},{"i":1202,"t":"Observing Messages","u":"/rlog/wakuv2-relay-anon","h":"#observing-messages","p":1170},{"i":1204,"t":"Correlation","u":"/rlog/wakuv2-relay-anon","h":"#correlation","p":1170},{"i":1206,"t":"DoS","u":"/rlog/wakuv2-relay-anon","h":"#dos","p":1170},{"i":1208,"t":"Summary and Future Work","u":"/rlog/wakuv2-relay-anon","h":"#summary-and-future-work","p":1170},{"i":1210,"t":"References","u":"/rlog/wakuv2-relay-anon","h":"#references","p":1170},{"i":1214,"t":"What is a zkVM?","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1216,"t":"Why zkVMs matter","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1218,"t":"Our methodology","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1220,"t":"ZkVM project analysis","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1221,"t":"1. [SP1]","u":"/rlog/zkVM-explorations","h":"#1-sp1","p":1212},{"i":1223,"t":"2. [Nexus]","u":"/rlog/zkVM-explorations","h":"#2-nexus","p":1212},{"i":1225,"t":"3. [RISC0]","u":"/rlog/zkVM-explorations","h":"#3-risc0","p":1212},{"i":1227,"t":"4. [Powdr]","u":"/rlog/zkVM-explorations","h":"#4-powdr","p":1212},{"i":1229,"t":"5. [ZkMIPS]","u":"/rlog/zkVM-explorations","h":"#5-zkmips","p":1212},{"i":1231,"t":"6. [Valida]","u":"/rlog/zkVM-explorations","h":"#6-valida","p":1212},{"i":1233,"t":"7. [Jolt]","u":"/rlog/zkVM-explorations","h":"#7-jolt","p":1212},{"i":1235,"t":"8. [ZkWASM]","u":"/rlog/zkVM-explorations","h":"#8-zkwasm","p":1212},{"i":1237,"t":"9. [Aleo]","u":"/rlog/zkVM-explorations","h":"#9-aleo","p":1212},{"i":1239,"t":"10. [Ola]","u":"/rlog/zkVM-explorations","h":"#10-ola","p":1212},{"i":1241,"t":"11. [Miden]","u":"/rlog/zkVM-explorations","h":"#11-miden","p":1212},{"i":1243,"t":"12. [ZkOS]","u":"/rlog/zkVM-explorations","h":"#12-zkos","p":1212},{"i":1245,"t":"13. [Triton]","u":"/rlog/zkVM-explorations","h":"#13-triton","p":1212},{"i":1247,"t":"14. [Cairo]","u":"/rlog/zkVM-explorations","h":"#14-cairo","p":1212},{"i":1249,"t":"15. [SnarkOS]","u":"/rlog/zkVM-explorations","h":"#15-snarkos","p":1212},{"i":1251,"t":"16. [Lurk]","u":"/rlog/zkVM-explorations","h":"#16-lurk","p":1212},{"i":1253,"t":"17. [Piecrust]","u":"/rlog/zkVM-explorations","h":"#17-piecrust","p":1212},{"i":1255,"t":"18. [Ceno]","u":"/rlog/zkVM-explorations","h":"#18-ceno","p":1212},{"i":1257,"t":"19. [Stellar]","u":"/rlog/zkVM-explorations","h":"#19-stellar","p":1212},{"i":1259,"t":"20. [NovaNet]","u":"/rlog/zkVM-explorations","h":"#20-novanet","p":1212},{"i":1261,"t":"21. [ZkLLVM]","u":"/rlog/zkVM-explorations","h":"#21-zkllvm","p":1212},{"i":1263,"t":"22. [ZkMove]","u":"/rlog/zkVM-explorations","h":"#22-zkmove","p":1212},{"i":1265,"t":"23. [O1VM]","u":"/rlog/zkVM-explorations","h":"#23-o1vm","p":1212},{"i":1267,"t":"Summary of findings","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1269,"t":"Insights and conclusions","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1271,"t":"References","u":"/rlog/zkVM-explorations","h":"","p":1212},{"i":1277,"t":"Why these candidates?","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1279,"t":"Preliminary information on the candidates","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1281,"t":"Testing plan","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1283,"t":"Machine specifications","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1285,"t":"Results","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1286,"t":"1. SP1","u":"/rlog/zkVM-testing","h":"#1-sp1","p":1275},{"i":1288,"t":"2. RISC0","u":"/rlog/zkVM-testing","h":"#2-risc0","p":1275},{"i":1290,"t":"3. Nexus","u":"/rlog/zkVM-testing","h":"#3-nexus","p":1275},{"i":1292,"t":"4. ZkMIPS","u":"/rlog/zkVM-testing","h":"#4-zkmips","p":1275},{"i":1294,"t":"5. ZkWASM","u":"/rlog/zkVM-testing","h":"#5-zkwasm","p":1275},{"i":1296,"t":"6. Valida","u":"/rlog/zkVM-testing","h":"#6-valida","p":1275},{"i":1298,"t":"Summary table","u":"/rlog/zkVM-testing","h":"#summary-table","p":1275},{"i":1299,"t":"Stage 1","u":"/rlog/zkVM-testing","h":"#stage-1","p":1275},{"i":1301,"t":"Stage 2","u":"/rlog/zkVM-testing","h":"#stage-2","p":1275},{"i":1303,"t":"Summary","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1305,"t":"References","u":"/rlog/zkVM-testing","h":"","p":1275},{"i":1308,"t":"How to Contribute","u":"/contribute","h":"#how-to-contribute","p":1307},{"i":1310,"t":"What to Contribute","u":"/contribute","h":"#what-to-contribute","p":1307},{"i":1318,"t":"1) Who we are","u":"/privacy-policy","h":"#1-who-we-are","p":1316},{"i":1320,"t":"2) We limit the collection and processing of personal data from your use of the Website","u":"/privacy-policy","h":"#2-we-limit-the-collection-and-processing-of-personal-data-from-your-use-of-the-website","p":1316},{"i":1322,"t":"3) Third party processing of personal data","u":"/privacy-policy","h":"#3-third-party-processing-of-personal-data","p":1316},{"i":1324,"t":"4) Security measures we take in respect of the Website","u":"/privacy-policy","h":"#4-security-measures-we-take-in-respect-of-the-website","p":1316},{"i":1326,"t":"5) Exporting data outside the European Union and Switzerland","u":"/privacy-policy","h":"#5-exporting-data-outside-the-european-union-and-switzerland","p":1316},{"i":1328,"t":"6) Your choices and rights","u":"/privacy-policy","h":"#6-your-choices-and-rights","p":1316},{"i":1330,"t":"7) Third party links","u":"/privacy-policy","h":"#7-third-party-links","p":1316},{"i":1332,"t":"8) This Privacy Policy might change","u":"/privacy-policy","h":"#8-this-privacy-policy-might-change","p":1316},{"i":1334,"t":"9) Contact information","u":"/privacy-policy","h":"#9-contact-information","p":1316},{"i":1338,"t":"Principles","u":"/principles","h":"","p":1336},{"i":1340,"t":"I. Liberty","u":"/principles","h":"#i-liberty","p":1336},{"i":1342,"t":"II. Censorship resistance","u":"/principles","h":"#ii-censorship-resistance","p":1336},{"i":1344,"t":"III. Security","u":"/principles","h":"#iii-security","p":1336},{"i":1346,"t":"IV. Privacy","u":"/principles","h":"#iv-privacy","p":1336},{"i":1348,"t":"V. Transparency","u":"/principles","h":"#v-transparency","p":1336},{"i":1350,"t":"VI. Openness","u":"/principles","h":"#vi-openness","p":1336},{"i":1352,"t":"VII. Decentralisation","u":"/principles","h":"#vii-decentralisation","p":1336},{"i":1354,"t":"VIII. Inclusivity","u":"/principles","h":"#viii-inclusivity","p":1336},{"i":1356,"t":"IX. Continuance","u":"/principles","h":"#ix-continuance","p":1336},{"i":1358,"t":"X. Resourcefulness","u":"/principles","h":"#x-resourcefulness","p":1336},{"i":1365,"t":"Papers","u":"/publications","h":"#papers","p":1364},{"i":1367,"t":"Write-ups","u":"/publications","h":"#write-ups","p":1364},{"i":1371,"t":"Why RLN","u":"/rln","h":"#why-rln","p":1369},{"i":1373,"t":"What is RLN","u":"/rln","h":"#what-is-rln","p":1369},{"i":1375,"t":"How RLN Works","u":"/rln","h":"#how-rln-works","p":1369},{"i":1377,"t":"Resources","u":"/rln","h":"#resources","p":1369},{"i":1378,"t":"Docs","u":"/rln","h":"#docs","p":1369},{"i":1380,"t":"Implementations","u":"/rln","h":"#implementations","p":1369},{"i":1382,"t":"Integrations / Use Cases","u":"/rln","h":"#integrations--use-cases","p":1369},{"i":1384,"t":"Talks & References","u":"/rln","h":"#talks--references","p":1369},{"i":1388,"t":"1) Who we are","u":"/terms","h":"#1-who-we-are","p":1386},{"i":1390,"t":"2) Disclaimers","u":"/terms","h":"#2-disclaimers","p":1386},{"i":1392,"t":"3) Forward looking statements","u":"/terms","h":"#3-forward-looking-statements","p":1386},{"i":1394,"t":"4) Intellectual property rights","u":"/terms","h":"#4-intellectual-property-rights","p":1386},{"i":1396,"t":"5) Third-party website links","u":"/terms","h":"#5-third-party-website-links","p":1386},{"i":1398,"t":"6) Limitation of liability","u":"/terms","h":"#6-limitation-of-liability","p":1386},{"i":1400,"t":"7) Indemnity","u":"/terms","h":"#7-indemnity","p":1386},{"i":1402,"t":"8) Modifications","u":"/terms","h":"#8-modifications","p":1386},{"i":1404,"t":"9) Governing law","u":"/terms","h":"#9-governing-law","p":1386},{"i":1406,"t":"10) Disputes","u":"/terms","h":"#10-disputes","p":1386},{"i":1408,"t":"11) About these Website Terms of Use","u":"/terms","h":"#11-about-these-website-terms-of-use","p":1386},{"i":1414,"t":"Nescience","u":"/vips","h":"#nescience","p":1412},{"i":1418,"t":"P2P","u":"/vsus","h":"#p2p","p":1416},{"i":1420,"t":"Token Economics (TKE)","u":"/vsus","h":"#token-economics-tke","p":1416},{"i":1422,"t":"Distributed Systems Testing (DST)","u":"/vsus","h":"#distributed-systems-testing-dst","p":1416},{"i":1424,"t":"Quality Assurance (QA)","u":"/vsus","h":"#quality-assurance-qa","p":1416},{"i":1426,"t":"Smart Contracts (SC)","u":"/vsus","h":"#smart-contracts-sc","p":1416},{"i":1428,"t":"Nim","u":"/vsus","h":"#nim","p":1416},{"i":1430,"t":"Applied Cryptography & ZK (ACZ)","u":"/vsus","h":"#applied-cryptography--zk-acz","p":1416},{"i":1432,"t":"RFC","u":"/vsus","h":"#rfc","p":1416},{"i":1434,"t":"Security","u":"/vsus","h":"#security","p":1416}],"index":{"version":"2.3.9","fields":["t"],"fieldVectors":[["t/3",[0,5.361]],["t/5",[1,5.731]],["t/7",[2,4.764,3,4.652]],["t/9",[4,5.358,5,4.794,6,5.358]],["t/11",[1,5.731]],["t/13",[2,4.764,3,4.652]],["t/15",[7,5.358,8,5.358,9,5.358]],["t/17",[1,5.731]],["t/19",[2,4.764,3,4.652]],["t/21",[10,7.532]],["t/23",[1,5.731]],["t/25",[2,4.764,3,4.652]],["t/27",[11,4.4,12,4.682,13,4.189,14,4.682]],["t/29",[1,5.731]],["t/31",[2,4.764,3,4.652]],["t/33",[15,5.881]],["t/35",[1,5.731]],["t/37",[2,4.764,3,4.652]],["t/39",[16,4.4,17,3.881,18,4.021,19,4.682]],["t/41",[1,5.731]],["t/43",[2,4.764,3,4.652]],["t/45",[20,6.05]],["t/47",[1,5.731]],["t/49",[21,5.035,22,4.794,23,5.358]],["t/51",[1,5.731]],["t/53",[2,4.764,3,4.652]],["t/55",[24,6.834,25,6.834]],["t/60",[26,5.161]],["t/62",[27,5.731]],["t/63",[28,7.532]],["t/65",[29,3.532]],["t/67",[28,6.261,30,6.834]],["t/69",[29,2.936,31,5.377]],["t/71",[32,6.468]],["t/73",[33,2.667,34,3.907,35,4.158,36,3.907,37,3.34]],["t/75",[38,3.387,39,5.358,40,5.848]],["t/77",[34,3.514,39,3.739,41,2.517,42,4.081,43,4.081,44,3.739]],["t/79",[35,4.158,36,3.907,37,3.34,45,2.959,46,2.959]],["t/81",[46,2.959,47,2.959,48,3.72,49,2.959,50,4.158]],["t/83",[34,3.514,49,2.661,50,3.739,51,2.845,52,4.081,53,4.081]],["t/85",[54,4.021,55,4.4,56,4.682,57,4.021]],["t/87",[56,5.358,57,4.601,58,4.601]],["t/89",[48,4.189,59,4.021,60,4.682,61,2.878]],["t/91",[61,3.293,62,4.601,63,5.848]],["t/93",[11,4.4,36,4.4,61,2.878,64,4.4]],["t/95",[65,7.078]],["t/97",[66,5.848,67,5.848,68,5.848]],["t/99",[69,4.986]],["t/101",[70,4.215,71,4.55]],["t/103",[72,4.249]],["t/108",[27,5.731]],["t/110",[73,7.532]],["t/112",[65,5.884,74,6.834]],["t/114",[65,4.4,75,5.11,76,5.11,77,4.682]],["t/116",[78,6.834,79,5.377]],["t/118",[69,4.986]],["t/122",[80,7.532]],["t/124",[]],["t/126",[81,4.682,82,3.332,83,3.881,84,4.021]],["t/128",[84,5.377,85,6.261]],["t/130",[13,4.189,82,3.332,83,3.881,84,4.021]],["t/132",[29,3.532]],["t/134",[29,2.512,86,5.358,87,3.813]],["t/136",[29,2.512,88,3.249,89,5.035]],["t/138",[29,2.936,90,4.457]],["t/140",[90,2.959,91,4.538,92,3.446,93,2.709,94,3.72]],["t/142",[32,4.601,93,3.491,95,4.077]],["t/144",[93,4.079,96,5.884]],["t/146",[93,3.05,97,5.11,98,4.682,99,5.11]],["t/148",[93,4.079,94,5.602]],["t/150",[93,2.709,94,3.72,100,4.538,101,4.158,102,3.907]],["t/152",[103,3.907,104,4.158,105,3.246,106,4.158,107,4.158]],["t/154",[108,8.221]],["t/156",[109,7.532]],["t/158",[110,5.731]],["t/162",[111,5.377,112,5.884]],["t/164",[69,4.986]],["t/166",[72,4.249]],["t/172",[26,5.161]],["t/174",[113,4.652,114,6.834]],["t/176",[113,4.652,115,5.19]],["t/178",[116,7.532]],["t/180",[113,3.981,115,4.441,117,5.848]],["t/182",[118,5.377,119,5.377]],["t/184",[113,3.981,115,4.441,120,5.358]],["t/186",[113,3.981,115,4.441,121,5.848]],["t/188",[118,5.377,122,6.834]],["t/190",[113,4.652,123,6.834]],["t/192",[72,4.249]],["t/196",[124,8.221]],["t/198",[125,6.834,126,6.261]],["t/200",[127,6.834,128,6.834]],["t/202",[105,4.183,129,5.035,130,4.601]],["t/203",[130,4.601,131,5.848,132,5.358]],["t/205",[129,5.035,130,4.601,133,5.848]],["t/207",[130,4.021,134,4.682,135,5.11,136,5.11]],["t/209",[69,4.986]],["t/211",[72,4.249]],["t/215",[137,5.377,138,4.652]],["t/217",[95,5.731]],["t/219",[139,8.221]],["t/221",[105,3.656,140,5.11,141,4.682,142,4.682]],["t/223",[143,5.358,144,5.848,145,4.183]],["t/225",[37,5.029,146,5.884]],["t/227",[87,4.457,147,5.602]],["t/229",[79,6.468]],["t/231",[148,5.602,149,6.261]],["t/233",[150,6.468]],["t/237",[151,4.021,152,4.682,153,4.682,154,4.682]],["t/239",[29,2.512,90,3.813,155,5.035]],["t/241",[156,5.848,157,4.794,158,5.848]],["t/243",[93,3.491,106,5.358,107,5.358]],["t/245",[29,2.196,90,3.332,159,3.656,160,5.11]],["t/247",[88,3.249,161,5.035,162,3.74]],["t/249",[138,4.652,163,5.884]],["t/251",[29,2.512,90,3.813,164,5.848]],["t/253",[72,4.249]],["t/257",[137,5.377,138,4.652]],["t/259",[138,4.652,165,6.261]],["t/261",[95,5.731]],["t/262",[166,5.377,167,6.834]],["t/264",[32,5.377,166,5.377]],["t/266",[168,4.601,169,4.441,170,4.794]],["t/268",[46,3.332,171,4.682,172,4.4,173,5.11]],["t/270",[174,5.884,175,6.834]],["t/272",[176,6.243]],["t/274",[174,5.884,176,5.19]],["t/276",[176,5.19,177,6.834]],["t/278",[148,5.602,149,6.261]],["t/280",[150,6.468]],["t/284",[26,5.161]],["t/286",[161,4.4,178,4.021,179,4.682,180,4.4]],["t/288",[181,8.221]],["t/290",[182,5.596]],["t/292",[180,7.078]],["t/294",[183,8.221]],["t/296",[29,2.936,184,5.884]],["t/297",[88,3.249,137,4.601,185,5.848]],["t/299",[29,2.512,171,5.358,186,5.848]],["t/301",[187,6.834,188,6.261]],["t/305",[189,8.221]],["t/307",[26,5.161]],["t/309",[190,5.11,191,5.11,192,5.11,193,4.682]],["t/311",[155,3.907,194,4.538,195,4.158,196,4.158,197,3.571]],["t/313",[198,5.848,199,5.035,200,5.035]],["t/315",[61,2.878,201,5.11,202,4.682,203,4.682]],["t/317",[161,5.884,204,6.834]],["t/319",[110,5.731]],["t/321",[72,4.249]],["t/325",[95,5.731]],["t/327",[205,7.532]],["t/329",[147,6.739]],["t/331",[72,4.249]],["t/335",[27,5.731]],["t/337",[20,3.003,29,1.753,33,2.399,206,3.739,207,4.081,208,3.739]],["t/339",[38,2.96,209,3.881,210,4.682,211,4.189]],["t/341",[41,3.607,209,4.441,212,5.848]],["t/343",[45,3.813,162,3.74,213,4.441]],["t/345",[162,3.74,214,5.035,215,4.441]],["t/347",[213,4.441,216,4.441,217,4.601]],["t/349",[29,1.95,87,2.959,88,2.522,162,2.902,218,4.158]],["t/351",[47,2.959,83,3.446,92,3.446,93,2.709,219,3.164]],["t/353",[70,4.215,71,4.55]],["t/355",[193,5.358,220,5.848,221,5.358]],["t/357",[222,3.907,223,4.538,224,3.164,225,4.158,226,4.538]],["t/359",[88,3.797,157,5.602]],["t/361",[209,4.441,227,5.848,228,5.848]],["t/363",[162,4.37,229,6.834]],["t/365",[72,4.249]],["t/369",[137,6.468]],["t/371",[138,4.652,230,6.834]],["t/373",[209,5.19,231,6.261]],["t/374",[33,2.399,61,2.298,203,3.739,232,3.739,233,3.739,234,3.514]],["t/376",[38,2.96,152,4.682,235,5.11,236,4.682]],["t/378",[41,3.152,237,5.11,238,5.11,239,5.11]],["t/380",[45,3.813,61,3.293,240,5.848]],["t/382",[47,2.959,61,2.555,241,4.538,242,4.538,243,4.538]],["t/384",[110,5.731]],["t/386",[72,4.249]],["t/390",[95,5.731]],["t/392",[61,2.878,233,4.682,234,4.4,244,5.11]],["t/394",[88,3.797,195,6.261]],["t/395",[245,4.538,246,4.538,247,4.538,248,4.538,249,4.538]],["t/397",[57,4.601,216,4.441,250,5.848]],["t/399",[57,4.601,216,4.441,251,5.848]],["t/401",[205,7.532]],["t/403",[79,6.468]],["t/405",[147,6.739]],["t/407",[72,4.249]],["t/411",[252,8.221]],["t/413",[16,5.035,146,5.035,253,4.794]],["t/415",[254,7.532]],["t/417",[255,8.221]],["t/419",[256,6.739]],["t/423",[26,5.161]],["t/425",[33,2.399,48,3.345,182,2.778,257,2.845,258,3.345,259,3.099]],["t/427",[132,4.682,259,3.881,260,5.11,261,5.11]],["t/429",[17,4.441,262,5.848,263,5.848]],["t/431",[73,6.261,264,5.377]],["t/433",[38,2.628,55,3.907,182,3.089,265,3.72,266,3.571]],["t/435",[200,3.907,267,4.538,268,4.538,269,4.538,270,3.907]],["t/437",[17,3.446,200,3.907,271,4.538,272,4.538,273,4.538]],["t/439",[31,5.377,274,6.834]],["t/441",[41,2.799,55,3.907,118,3.571,182,3.089,275,4.158]],["t/443",[45,2.661,182,2.778,215,3.099,259,3.099,276,4.081,277,3.003]],["t/445",[47,2.959,89,3.907,182,3.089,197,3.571,278,4.538]],["t/447",[31,2.673,51,2.368,82,2.215,88,1.887,182,2.312,279,3.397,280,2.924,281,3.112]],["t/449",[51,3.563,182,3.479,282,5.11,283,4.682]],["t/451",[110,4.764,259,5.19]],["t/453",[257,4.764,284,5.884]],["t/455",[72,4.249]],["t/457",[285,7.078]],["t/461",[20,2.306,105,2.242,141,2.871,210,2.871,222,2.698,286,3.134,287,3.134,288,3.134,289,3.134]],["t/463",[20,3.003,79,3.211,202,3.739,290,4.081,291,4.081,292,4.081]],["t/465",[20,5.029,293,6.834]],["t/467",[20,4.304,294,5.358,295,5.848]],["t/471",[137,5.377,138,4.652]],["t/473",[15,5.881]],["t/475",[145,4.183,296,5.848,297,4.601]],["t/477",[298,8.221]],["t/479",[232,6.261,299,5.602]],["t/481",[300,4.682,301,5.11,302,5.11,303,5.11]],["t/483",[166,5.377,304,6.261]],["t/485",[111,4.601,305,5.848,306,5.848]],["t/487",[166,4.021,199,4.4,307,5.11,308,5.11]],["t/489",[70,4.215,71,4.55]],["t/492",[0,2.044,18,2.466,265,2.569,266,2.466,309,2.242,310,3.134,311,3.134,312,2.698,313,2.698]],["t/494",[265,2.569,266,2.466,309,2.242,312,2.698,313,2.698,314,3.134,315,2.698,316,3.134,317,3.134]],["t/496",[0,2.661,46,2.661,257,2.845,258,3.345,259,3.099,318,3.739]],["t/498",[119,2.917,319,2.815,320,3.708,321,2.917,322,4.275,323,3.039]],["t/500",[93,2.213,277,2.728,324,3.708,325,3.708,326,3.708,327,3.192,328,3.708]],["t/502",[93,2.436,101,3.739,118,3.211,329,4.081,330,3.739,331,4.081]],["t/504",[29,1.459,151,2.673,168,2.673,169,2.579,332,3.397,333,2.673,334,3.112,335,3.112]],["t/506",[15,2.081,61,1.638,90,1.897,196,2.665,197,2.289,209,2.209,216,2.209,336,2.909,337,2.909,338,2.909]],["t/508",[0,2.959,309,3.246,339,4.538,340,4.538,341,4.158]],["t/510",[29,2.688,111,3.211,112,3.514,342,3.739,343,4.081]],["t/514",[26,5.161]],["t/516",[116,4.682,344,4.682,345,4.4,346,5.11]],["t/518",[90,3.332,347,5.11,348,5.11,349,5.11]],["t/520",[224,2.368,344,3.112,345,2.924,350,3.397,351,3.397,352,3.397,353,3.397,354,3.397]],["t/522",[345,3.514,355,3.739,356,4.081,357,4.081,358,4.081,359,4.081]],["t/524",[77,4.158,277,3.34,355,4.158,360,4.538,361,4.538]],["t/526",[69,4.986]],["t/528",[72,4.249]],["t/532",[46,2.959,184,3.907,318,4.158,362,3.34,363,4.538]],["t/534",[362,3.34,364,4.158,365,4.538,366,3.72,367,4.538]],["t/536",[0,2.959,219,3.164,257,3.164,258,3.72,259,3.446]],["t/538",[82,2.661,219,2.845,368,3.345,369,4.081,370,4.081,371,4.081]],["t/540",[49,2.959,372,4.538,373,4.538,374,4.538,375,4.538]],["t/542",[69,4.986]],["t/544",[197,5.377,376,5.377]],["t/546",[33,3.437,377,5.848,378,5.035]],["t/548",[257,4.764,379,5.884]],["t/550",[103,5.035,257,4.077,376,4.601]],["t/552",[265,3.345,266,3.211,309,2.919,312,3.514,313,3.514,380,3.514]],["t/554",[362,3.761,366,4.189,381,4.682,382,4.682]],["t/556",[0,3.813,46,3.813,383,5.358]],["t/558",[21,4.4,22,4.189,362,3.761,384,4.682]],["t/560",[38,2.96,95,3.563,148,4.189,366,4.189]],["t/562",[46,4.457,385,6.261]],["t/564",[385,6.261,386,6.834]],["t/566",[41,2.799,366,3.72,387,3.907,388,3.571,389,3.907]],["t/568",[0,3.813,378,5.035,388,4.601]],["t/570",[148,3.72,376,3.571,388,3.571,390,4.538,391,4.158]],["t/572",[110,3.563,362,3.761,388,4.021,391,4.682]],["t/574",[362,3.761,380,4.4,392,5.11,393,5.11]],["t/576",[0,3.813,253,4.794,394,5.358]],["t/578",[48,2.784,60,3.112,219,3.779,253,2.784,368,2.784,388,2.673,395,2.784]],["t/580",[0,2.959,49,2.959,376,3.571,389,3.907,396,4.158]],["t/582",[49,4.457,397,6.834]],["t/584",[49,3.813,103,5.035,398,5.358]],["t/586",[49,3.813,379,5.035,399,5.358]],["t/588",[49,3.813,400,5.358,401,5.848]],["t/590",[49,3.813,270,5.035,402,5.358]],["t/592",[0,3.813,396,5.358,403,5.358]],["t/594",[69,4.145,404,6.261]],["t/596",[113,3.981,362,4.304,380,5.035]],["t/598",[13,3.039,82,2.418,280,3.192,309,2.652,383,3.397,405,3.708,406,3.708]],["t/600",[215,2.815,384,3.397,407,3.708,408,3.708,409,3.192,410,3.708,411,3.708]],["t/602",[0,3.332,70,3.152,381,4.682,412,4.189]],["t/604",[72,4.249]],["t/607",[29,2.688,342,3.739,413,4.081,414,2.363,415,3.739]],["t/609",[5,2.784,15,2.43,29,1.459,82,2.215,83,2.579,92,2.579,280,2.924,414,1.967]],["t/611",[29,1.753,61,2.298,159,2.919,319,3.099,414,2.363,416,3.514]],["t/613",[29,2.512,414,3.387,417,5.358]],["t/615",[29,2.196,412,4.189,414,2.96,418,4.189]],["t/617",[176,4.441,256,4.794,419,5.358]],["t/619",[420,5.035,421,5.848,422,5.358]],["t/621",[254,6.261,256,5.602]],["t/623",[29,2.936,417,6.261]],["t/625",[162,3.74,214,5.035,215,4.441]],["t/628",[29,1.753,70,2.517,90,2.661,155,3.514,157,3.345,423,4.081]],["t/630",[29,2.196,84,4.021,424,4.682,425,5.11]],["t/632",[81,4.682,82,3.332,83,3.881,84,4.021]],["t/634",[29,2.329,82,2.215,94,2.784,333,2.673,426,2.579,427,2.924,428,2.924]],["t/636",[29,1.753,49,2.661,217,3.211,409,3.514,429,3.345,430,3.211]],["t/638",[29,1.95,162,2.902,213,3.446,414,2.628,431,4.538]],["t/640",[184,5.884,208,6.261]],["t/642",[126,3.739,129,3.514,432,4.081,433,4.081,434,3.739,435,4.081]],["t/644",[29,2.496,199,3.192,414,2.147,436,2.917,437,3.397,438,3.192]],["t/646",[29,1.593,61,2.088,159,2.652,319,2.815,414,2.147,416,3.192,439,3.708]],["t/649",[29,2.512,178,4.601,440,5.848]],["t/651",[168,2.917,169,2.815,176,2.815,419,3.397,441,3.708,442,3.397,443,3.708]],["t/653",[15,3.246,145,3.246,297,3.571,444,4.158,445,4.158]],["t/655",[95,4.077,319,4.441,446,5.358]],["t/657",[15,3.656,145,3.656,297,4.021,447,5.11]],["t/661",[29,2.936,414,3.958]],["t/663",[29,2.512,414,3.387,415,5.358]],["t/665",[188,6.261,448,6.834]],["t/667",[418,5.602,449,5.884]],["t/671",[444,6.261,445,6.261]],["t/673",[428,7.078]],["t/675",[450,8.221]],["t/677",[32,6.468]],["t/678",[145,4.889,294,6.261]],["t/680",[89,5.884,300,6.261]],["t/682",[70,4.215,71,4.55]],["t/686",[26,5.161]],["t/688",[299,5.602,451,6.261]],["t/690",[113,2.778,234,3.514,297,3.211,452,3.739,453,4.081,454,3.739]],["t/692",[18,5.377,455,6.834]],["t/694",[452,7.532]],["t/696",[57,5.377,264,5.377]],["t/698",[456,7.532]],["t/700",[297,6.468]],["t/702",[44,6.261,327,5.884]],["t/704",[457,8.221]],["t/706",[118,5.377,458,6.834]],["t/708",[70,4.215,71,4.55]],["t/710",[69,4.986]],["t/712",[72,4.249]],["t/716",[26,5.161]],["t/718",[88,3.249,93,3.491,459,5.848]],["t/720",[46,2.959,98,4.158,409,3.907,460,4.538,461,4.538]],["t/722",[138,3.981,151,4.601,462,5.848]],["t/724",[46,3.332,151,4.021,334,4.682,463,5.11]],["t/726",[211,5.602,426,5.19]],["t/728",[224,4.764,426,5.19]],["t/730",[426,5.19,464,5.884]],["t/732",[93,2.709,299,3.72,465,4.538,466,4.538,467,4.158]],["t/734",[93,3.491,142,5.358,468,5.848]],["t/736",[70,4.215,71,4.55]],["t/738",[72,4.249]],["t/742",[166,5.377,469,5.884]],["t/744",[88,3.797,470,6.261]],["t/746",[138,3.981,446,5.358,471,5.848]],["t/750",[26,5.161]],["t/752",[92,5.19,472,6.834]],["t/754",[231,6.261,264,5.377]],["t/756",[17,4.441,61,3.293,473,5.848]],["t/758",[15,4.889,17,5.19]],["t/760",[174,5.884,469,5.884]],["t/762",[5,2.569,83,2.38,92,2.38,95,2.185,168,2.466,169,2.38,335,2.871,442,2.871,474,3.134]],["t/764",[32,6.468]],["t/766",[475,6.834,476,6.261]],["t/768",[113,3.479,115,3.881,119,4.021,477,5.11]],["t/770",[478,8.221]],["t/772",[479,7.078]],["t/774",[92,4.441,480,5.358,481,5.848]],["t/776",[163,5.035,176,4.441,236,5.358]],["t/778",[213,3.881,464,4.4,482,5.11,483,5.11]],["t/780",[327,3.514,456,3.739,484,4.081,485,4.081,486,4.081,487,4.081]],["t/782",[61,2.298,168,3.211,476,3.739,488,4.081,489,4.081,490,4.081]],["t/784",[69,3.547,70,3.607,491,5.035]],["t/786",[150,6.468]],["t/788",[72,4.249]],["t/790",[285,7.078]],["t/794",[26,5.161]],["t/796",[492,8.221]],["t/797",[113,2.778,115,3.099,119,3.211,454,3.739,493,3.211,494,4.081]],["t/799",[96,5.035,493,4.601,495,5.848]],["t/801",[96,5.035,451,5.358,496,5.848]],["t/803",[29,1.753,493,3.211,497,3.739,498,4.081,499,4.081,500,3.514]],["t/805",[29,1.593,480,3.397,493,2.917,500,3.192,501,3.708,502,3.708,503,3.708]],["t/807",[277,6.05]],["t/809",[211,5.602,504,6.834]],["t/811",[505,8.221]],["t/813",[275,7.532]],["t/815",[69,4.986]],["t/817",[70,4.215,71,4.55]],["t/819",[72,4.249]],["t/823",[27,5.731]],["t/826",[29,2.936,315,5.884]],["t/828",[38,3.387,225,5.358,424,5.358]],["t/830",[111,4.601,112,5.035,154,5.358]],["t/832",[506,8.221]],["t/834",[3,4.652,507,6.261]],["t/836",[72,4.249]],["t/840",[257,4.764,284,5.884]],["t/842",[29,2.196,46,3.332,508,5.11,509,4.4]],["t/844",[304,7.532]],["t/846",[29,2.196,178,4.021,364,4.682,510,5.11]],["t/848",[70,3.152,412,4.189,449,4.4,491,4.4]],["t/850",[150,6.468]],["t/854",[119,3.571,321,3.571,322,4.99,323,3.72]],["t/856",[321,5.377,322,5.029]],["t/858",[511,7.532]],["t/860",[170,6.739]],["t/862",[512,5.848,513,5.848,514,5.358]],["t/864",[321,4.021,322,3.761,515,5.11,516,5.11]],["t/866",[322,5.029,323,5.602]],["t/868",[170,6.739]],["t/870",[511,7.532]],["t/872",[321,3.571,322,4.99,323,3.72,437,4.158]],["t/874",[93,3.491,322,4.304,517,5.848]],["t/876",[72,4.249]],["t/880",[26,5.161]],["t/882",[88,3.797,518,6.834]],["t/884",[88,3.797,519,5.884]],["t/886",[88,3.249,395,4.794,520,5.035]],["t/888",[253,5.602,394,6.261]],["t/890",[521,4.441,522,4.441,523,4.794]],["t/892",[88,2.522,519,3.907,521,3.446,522,3.446,524,4.158]],["t/894",[88,2.268,395,3.345,520,3.514,521,3.099,522,3.099,524,3.739]],["t/896",[219,3.164,521,3.446,522,3.446,523,3.72,525,4.538]],["t/898",[88,2.268,519,3.514,521,3.099,522,3.099,523,3.345,526,4.081]],["t/900",[88,2.268,395,3.345,520,3.514,521,3.099,522,3.099,523,3.345]],["t/902",[69,4.986]],["t/904",[72,4.249]],["t/908",[26,5.161]],["t/910",[27,4.077,527,5.848,528,5.848]],["t/912",[29,2.936,414,3.958]],["t/913",[95,5.731]],["t/915",[182,5.596]],["t/917",[88,4.568]],["t/919",[277,6.05]],["t/921",[102,5.035,529,5.848,530,5.848]],["t/923",[109,7.532]],["t/925",[219,4.764,368,5.602]],["t/927",[29,2.196,37,3.761,414,2.96,531,5.11]],["t/929",[153,6.261,532,6.261]],["t/931",[61,3.293,159,4.183,533,5.848]],["t/933",[414,3.958,534,6.834]],["t/935",[170,5.602,535,6.834]],["t/937",[536,7.078]],["t/939",[69,4.986]],["t/943",[27,5.731]],["t/945",[29,2.196,179,4.682,209,3.881,414,2.96]],["t/947",[537,7.532]],["t/949",[90,3.813,438,5.035,538,5.848]],["t/950",[33,3.004,62,4.021,87,3.332,539,4.021]],["t/952",[38,2.96,87,3.332,539,4.021,540,5.11]],["t/954",[41,3.152,87,3.332,539,4.021,541,5.11]],["t/956",[45,3.332,87,3.332,539,4.021,542,5.11]],["t/958",[47,3.332,87,3.332,539,4.021,543,5.11]],["t/960",[544,8.221]],["t/962",[90,3.813,438,5.035,545,5.848]],["t/964",[69,4.986]],["t/966",[70,4.215,71,4.55]],["t/968",[72,4.249]],["t/972",[26,4.29,546,6.834]],["t/974",[29,2.183,33,1.842,178,2.466,319,2.38,414,1.815,427,2.698,436,2.466,547,3.134]],["t/975",[33,3.437,80,5.358,319,4.441]],["t/977",[29,2.196,38,2.96,178,4.021,436,4.021]],["t/979",[29,2.196,41,3.152,414,2.96,436,4.021]],["t/981",[29,1.95,182,3.089,197,3.571,414,2.628,548,4.538]],["t/983",[29,2.196,45,3.332,414,2.96,549,5.11]],["t/985",[29,2.196,47,3.332,414,2.96,550,4.682]],["t/987",[38,2.96,61,2.878,159,3.656,427,4.4]],["t/989",[51,4.077,61,3.293,159,4.183]],["t/991",[54,4.021,61,2.878,159,3.656,551,5.11]],["t/993",[58,4.021,418,4.189,422,4.682,552,5.11]],["t/995",[59,2.917,138,2.524,283,3.397,553,3.708,554,3.192,555,3.397,556,3.708]],["t/997",[62,5.377,557,6.834]],["t/1001",[138,5.596]],["t/1003",[558,8.221]],["t/1005",[264,6.468]],["t/1007",[559,8.221]],["t/1009",[33,3.004,507,4.682,560,4.4,561,4.682]],["t/1011",[33,4.017,562,6.834]],["t/1013",[38,3.387,88,3.249,563,5.848]],["t/1015",[31,4.601,41,3.607,564,5.848]],["t/1017",[37,3.761,45,3.332,565,5.11,566,5.11]],["t/1019",[47,3.332,61,2.878,567,5.11,568,5.11]],["t/1021",[29,1.753,51,2.845,105,2.919,436,3.211,561,3.739,569,4.081]],["t/1023",[38,2.96,222,4.4,479,4.4,560,4.4]],["t/1025",[33,4.017,216,5.19]],["t/1027",[37,4.304,38,3.387,570,5.848]],["t/1029",[41,4.215,571,6.834]],["t/1031",[41,2.517,46,2.661,87,2.661,467,3.739,560,3.514,572,3.514]],["t/1033",[33,3.004,86,4.682,87,3.332,573,4.682]],["t/1035",[38,3.958,572,5.884]],["t/1037",[41,2.799,299,3.72,555,4.158,574,4.538,575,4.158]],["t/1039",[45,2.044,87,2.044,157,2.569,330,2.871,500,2.698,576,3.134,577,3.134,578,3.134,579,2.871]],["t/1041",[47,3.813,104,5.358,580,5.358]],["t/1043",[172,5.884,221,6.261]],["t/1047",[581,8.221]],["t/1049",[257,4.764,284,5.884]],["t/1051",[582,8.221]],["t/1053",[277,6.05]],["t/1055",[102,5.884,583,6.834]],["t/1057",[29,2.512,580,5.358,584,5.848]],["t/1059",[554,5.884,585,6.834]],["t/1061",[586,6.834,587,6.834]],["t/1063",[550,7.532]],["t/1067",[87,3.813,588,5.358,589,5.848]],["t/1069",[162,3.74,214,5.035,215,4.441]],["t/1071",[162,4.37,218,6.261]],["t/1073",[27,4.764,590,6.261]],["t/1075",[162,3.74,591,5.358,592,5.358]],["t/1077",[211,4.189,591,4.682,592,4.682,593,5.11]],["t/1079",[90,2.959,162,2.902,258,3.72,264,3.571,594,4.538]],["t/1081",[37,4.304,162,3.74,256,4.794]],["t/1083",[590,6.261,595,5.602]],["t/1085",[88,3.249,213,4.441,217,4.601]],["t/1087",[88,2.84,162,3.268,165,4.682,596,5.11]],["t/1089",[88,2.84,213,3.881,216,3.881,217,4.021]],["t/1091",[573,6.261,597,6.834]],["t/1093",[143,6.261,598,6.834]],["t/1095",[69,3.547,70,3.607,599,5.848]],["t/1097",[72,4.249]],["t/1101",[26,5.161]],["t/1103",[49,3.332,217,4.021,600,5.11,601,5.11]],["t/1105",[49,3.332,379,4.4,402,4.682,588,4.682]],["t/1107",[88,3.249,281,5.358,429,4.794]],["t/1109",[61,3.848,602,6.834]],["t/1111",[257,4.077,429,4.794,603,5.848]],["t/1113",[29,2.196,429,4.189,430,4.021,509,4.4]],["t/1115",[430,5.377,604,6.834]],["t/1117",[430,5.377,605,6.834]],["t/1119",[430,4.601,606,5.848,607,5.848]],["t/1121",[111,3.571,389,3.907,509,3.907,608,4.538,609,4.538]],["t/1123",[69,4.986]],["t/1125",[70,4.215,491,5.884]],["t/1127",[72,4.249]],["t/1131",[27,5.731]],["t/1132",[46,3.332,420,4.4,610,5.11,611,5.11]],["t/1134",[71,3.402,180,4.4,420,4.4,612,5.11]],["t/1136",[613,8.221]],["t/1138",[33,4.017,614,6.261]],["t/1140",[38,3.958,614,6.261]],["t/1142",[378,5.884,615,6.834]],["t/1144",[27,3.563,85,4.682,159,3.656,470,4.682]],["t/1146",[572,3.192,616,3.708,617,3.708,618,3.708,619,3.708,620,3.708,621,3.708]],["t/1148",[376,4.601,479,5.035,622,5.848]],["t/1150",[464,4.4,575,4.682,623,5.11,624,5.11]],["t/1152",[61,4.629]],["t/1154",[22,4.189,625,5.11,626,5.11,627,5.11]],["t/1156",[224,4.077,628,5.848,629,5.848]],["t/1158",[120,5.358,532,5.358,630,5.848]],["t/1160",[206,7.532]],["t/1162",[418,5.602,449,5.884]],["t/1164",[150,6.468]],["t/1166",[72,4.249]],["t/1168",[285,7.078]],["t/1172",[82,2.959,224,3.164,333,3.571,428,3.907,631,3.907]],["t/1174",[224,5.731]],["t/1176",[82,5.361]],["t/1178",[333,6.468]],["t/1180",[333,5.377,632,6.834]],["t/1182",[633,6.261,634,6.261]],["t/1184",[382,6.261,595,5.602]],["t/1186",[134,7.532]],["t/1188",[497,7.532]],["t/1190",[215,3.881,426,3.881,595,4.189,635,5.11]],["t/1192",[172,7.078]],["t/1194",[90,3.332,514,4.682,636,5.11,637,4.682]],["t/1196",[595,5.602,638,6.834]],["t/1198",[434,6.261,639,6.261]],["t/1200",[639,6.261,640,6.834]],["t/1202",[61,3.848,641,6.834]],["t/1204",[642,8.221]],["t/1206",[151,6.468]],["t/1208",[70,3.607,71,3.893,110,4.077]],["t/1210",[72,4.249]],["t/1214",[309,5.881]],["t/1216",[309,4.889,643,6.834]],["t/1218",[537,7.532]],["t/1220",[309,4.183,315,5.035,426,4.441]],["t/1221",[33,4.017,644,6.261]],["t/1223",[38,3.958,645,6.261]],["t/1225",[41,4.215,646,6.261]],["t/1227",[45,4.457,647,6.834]],["t/1229",[47,4.457,648,6.261]],["t/1231",[51,4.764,649,6.261]],["t/1233",[54,5.377,650,6.834]],["t/1235",[58,5.377,651,6.261]],["t/1237",[59,5.377,652,6.834]],["t/1239",[62,5.377,653,6.834]],["t/1241",[64,5.884,654,6.834]],["t/1243",[655,6.834,656,6.834]],["t/1245",[657,6.834,658,6.834]],["t/1247",[659,6.834,660,6.834]],["t/1249",[661,6.834,662,6.834]],["t/1251",[663,6.834,664,6.834]],["t/1253",[665,6.834,666,6.834]],["t/1255",[667,6.834,668,6.834]],["t/1257",[669,6.834,670,6.834]],["t/1259",[671,6.834,672,6.834]],["t/1261",[673,6.834,674,6.834]],["t/1263",[675,6.834,676,6.834]],["t/1265",[677,6.834,678,6.834]],["t/1267",[110,4.764,147,5.602]],["t/1269",[69,4.145,679,6.834]],["t/1271",[72,4.249]],["t/1277",[680,7.532]],["t/1279",[631,5.035,680,5.358,681,5.848]],["t/1281",[18,5.377,412,5.602]],["t/1283",[266,5.377,637,6.261]],["t/1285",[79,6.468]],["t/1286",[33,4.017,644,6.261]],["t/1288",[38,3.958,646,6.261]],["t/1290",[41,4.215,645,6.261]],["t/1292",[45,4.457,648,6.261]],["t/1294",[47,4.457,651,6.261]],["t/1296",[51,4.764,649,6.261]],["t/1298",[110,4.764,146,5.884]],["t/1299",[33,4.017,682,6.261]],["t/1301",[38,3.958,682,6.261]],["t/1303",[110,5.731]],["t/1305",[72,4.249]],["t/1308",[536,7.078]],["t/1310",[536,7.078]],["t/1318",[33,4.832]],["t/1320",[38,1.967,145,2.43,169,2.579,219,2.368,387,2.924,683,3.397,684,3.112,685,2.784]],["t/1322",[41,2.517,145,2.919,387,3.514,684,3.739,686,3.514,687,3.514]],["t/1324",[45,2.661,224,2.845,685,3.345,688,4.081,689,4.081,690,4.081]],["t/1326",[47,2.418,145,2.652,691,3.708,692,3.708,693,3.708,694,3.708,695,3.708]],["t/1328",[51,4.077,696,5.848,697,5.358]],["t/1330",[54,4.021,686,4.4,687,4.4,698,4.682]],["t/1332",[58,4.021,82,3.332,579,4.682,699,5.11]],["t/1334",[59,4.601,631,5.035,700,5.848]],["t/1338",[701,8.221]],["t/1340",[702,8.221]],["t/1342",[398,5.358,633,5.358,634,5.358]],["t/1344",[224,4.764,399,6.261]],["t/1346",[82,4.457,400,6.261]],["t/1348",[270,5.884,703,6.834]],["t/1350",[163,5.884,403,6.261]],["t/1352",[404,6.261,704,6.834]],["t/1354",[705,6.834,706,6.834]],["t/1356",[707,6.834,708,6.834]],["t/1358",[709,6.834,710,6.261]],["t/1365",[711,8.221]],["t/1367",[554,5.884,712,6.834]],["t/1371",[93,4.907]],["t/1373",[93,4.907]],["t/1375",[71,4.55,93,4.079]],["t/1377",[710,7.532]],["t/1378",[713,8.221]],["t/1380",[277,6.05]],["t/1382",[31,4.021,105,3.656,219,3.563,368,4.189]],["t/1384",[72,3.023,105,4.183,416,5.035]],["t/1388",[33,4.832]],["t/1390",[38,3.958,714,6.834]],["t/1392",[2,3.563,3,3.479,41,3.152,715,5.11]],["t/1394",[45,3.332,341,4.682,697,4.682,716,5.11]],["t/1396",[47,2.959,685,3.72,686,3.907,687,3.907,698,4.158]],["t/1398",[51,4.077,169,4.441,717,5.848]],["t/1400",[54,5.377,718,6.834]],["t/1402",[58,5.377,493,5.377]],["t/1404",[59,4.601,130,4.601,719,5.848]],["t/1406",[62,5.377,720,6.834]],["t/1408",[64,4.4,219,3.563,469,4.4,685,4.189]],["t/1414",[0,5.361]],["t/1418",[15,5.881]],["t/1420",[4,5.358,5,4.794,6,5.358]],["t/1422",[16,4.4,17,3.881,18,4.021,19,4.682]],["t/1424",[7,5.358,8,5.358,9,5.358]],["t/1426",[21,5.035,22,4.794,23,5.358]],["t/1428",[20,6.05]],["t/1430",[11,3.907,12,4.158,13,3.72,14,4.158,105,3.246]],["t/1432",[10,7.532]],["t/1434",[224,5.731]]],"invertedIndex":[["",{"_index":105,"t":{"152":{"position":[[19,1]]},"202":{"position":[[7,2]]},"221":{"position":[[4,1]]},"461":{"position":[[9,1]]},"1021":{"position":[[11,3]]},"1382":{"position":[[13,1]]},"1384":{"position":[[6,1]]},"1430":{"position":[[21,1]]}}}],["0",{"_index":546,"t":{"972":{"position":[[0,2]]}}}],["1",{"_index":33,"t":{"73":{"position":[[0,2]]},"337":{"position":[[0,2]]},"374":{"position":[[0,2]]},"425":{"position":[[5,2]]},"546":{"position":[[0,2]]},"950":{"position":[[10,2]]},"974":{"position":[[5,1]]},"975":{"position":[[0,2]]},"1009":{"position":[[6,1]]},"1011":{"position":[[0,2]]},"1025":{"position":[[0,2]]},"1033":{"position":[[0,2]]},"1138":{"position":[[13,1]]},"1221":{"position":[[0,2]]},"1286":{"position":[[0,2]]},"1299":{"position":[[6,1]]},"1318":{"position":[[0,2]]},"1388":{"position":[[0,2]]}}}],["10",{"_index":62,"t":{"91":{"position":[[0,3]]},"950":{"position":[[13,2]]},"997":{"position":[[0,3]]},"1239":{"position":[[0,3]]},"1406":{"position":[[0,3]]}}}],["101",{"_index":320,"t":{"498":{"position":[[4,4]]}}}],["11",{"_index":64,"t":{"93":{"position":[[0,3]]},"1241":{"position":[[0,3]]},"1408":{"position":[[0,3]]}}}],["12",{"_index":655,"t":{"1243":{"position":[[0,3]]}}}],["13",{"_index":657,"t":{"1245":{"position":[[0,3]]}}}],["14",{"_index":659,"t":{"1247":{"position":[[0,3]]}}}],["15",{"_index":661,"t":{"1249":{"position":[[0,3]]}}}],["150",{"_index":543,"t":{"958":{"position":[[13,3]]}}}],["16",{"_index":663,"t":{"1251":{"position":[[0,3]]}}}],["17",{"_index":665,"t":{"1253":{"position":[[0,3]]}}}],["18",{"_index":667,"t":{"1255":{"position":[[0,3]]}}}],["19",{"_index":669,"t":{"1257":{"position":[[0,3]]}}}],["2",{"_index":38,"t":{"75":{"position":[[0,2]]},"339":{"position":[[0,2]]},"376":{"position":[[0,2]]},"433":{"position":[[5,2]]},"560":{"position":[[0,2]]},"828":{"position":[[6,1]]},"952":{"position":[[10,2]]},"977":{"position":[[0,2]]},"987":{"position":[[5,1]]},"1013":{"position":[[0,2]]},"1023":{"position":[[6,1]]},"1027":{"position":[[0,2]]},"1035":{"position":[[0,2]]},"1140":{"position":[[13,1]]},"1223":{"position":[[0,2]]},"1288":{"position":[[0,2]]},"1301":{"position":[[6,1]]},"1320":{"position":[[0,2]]},"1390":{"position":[[0,2]]}}}],["2,653",{"_index":453,"t":{"690":{"position":[[37,5]]}}}],["2.2",{"_index":286,"t":{"461":{"position":[[4,3]]}}}],["20",{"_index":671,"t":{"1259":{"position":[[0,3]]}}}],["2025",{"_index":25,"t":{"55":{"position":[[13,4]]}}}],["21",{"_index":673,"t":{"1261":{"position":[[0,3]]}}}],["22",{"_index":675,"t":{"1263":{"position":[[0,3]]}}}],["23",{"_index":677,"t":{"1265":{"position":[[0,3]]}}}],["3",{"_index":41,"t":{"77":{"position":[[0,2]]},"341":{"position":[[0,2]]},"378":{"position":[[0,2]]},"441":{"position":[[5,2]]},"566":{"position":[[0,2]]},"954":{"position":[[10,2]]},"979":{"position":[[0,2]]},"1015":{"position":[[0,2]]},"1029":{"position":[[0,2]]},"1031":{"position":[[6,1]]},"1037":{"position":[[0,2]]},"1225":{"position":[[0,2]]},"1290":{"position":[[0,2]]},"1322":{"position":[[0,2]]},"1392":{"position":[[0,2]]}}}],["3.5",{"_index":548,"t":{"981":{"position":[[0,3]]}}}],["30",{"_index":540,"t":{"952":{"position":[[13,2]]}}}],["4",{"_index":45,"t":{"79":{"position":[[0,2]]},"343":{"position":[[0,2]]},"380":{"position":[[0,2]]},"443":{"position":[[5,2]]},"956":{"position":[[10,2]]},"983":{"position":[[0,2]]},"1017":{"position":[[0,2]]},"1039":{"position":[[0,2]]},"1227":{"position":[[0,2]]},"1292":{"position":[[0,2]]},"1324":{"position":[[0,2]]},"1394":{"position":[[0,2]]}}}],["5",{"_index":47,"t":{"81":{"position":[[0,2]]},"351":{"position":[[0,2]]},"382":{"position":[[0,2]]},"445":{"position":[[5,2]]},"958":{"position":[[10,2]]},"985":{"position":[[0,2]]},"1019":{"position":[[0,2]]},"1041":{"position":[[0,2]]},"1229":{"position":[[0,2]]},"1294":{"position":[[0,2]]},"1326":{"position":[[0,2]]},"1396":{"position":[[0,2]]}}}],["50",{"_index":541,"t":{"954":{"position":[[13,2]]}}}],["6",{"_index":51,"t":{"83":{"position":[[0,2]]},"447":{"position":[[5,2]]},"449":{"position":[[27,1]]},"989":{"position":[[0,2]]},"1021":{"position":[[0,2]]},"1231":{"position":[[0,2]]},"1296":{"position":[[0,2]]},"1328":{"position":[[0,2]]},"1398":{"position":[[0,2]]}}}],["7",{"_index":54,"t":{"85":{"position":[[0,2]]},"991":{"position":[[0,2]]},"1233":{"position":[[0,2]]},"1330":{"position":[[0,2]]},"1400":{"position":[[0,2]]}}}],["8",{"_index":58,"t":{"87":{"position":[[0,2]]},"993":{"position":[[0,2]]},"1235":{"position":[[0,2]]},"1332":{"position":[[0,2]]},"1402":{"position":[[0,2]]}}}],["85",{"_index":542,"t":{"956":{"position":[[13,2]]}}}],["9",{"_index":59,"t":{"89":{"position":[[0,2]]},"995":{"position":[[0,2]]},"1237":{"position":[[0,2]]},"1334":{"position":[[0,2]]},"1404":{"position":[[0,2]]}}}],["account",{"_index":572,"t":{"1031":{"position":[[10,10]]},"1035":{"position":[[3,10]]},"1146":{"position":[[0,7]]}}}],["achiev",{"_index":448,"t":{"665":{"position":[[0,12]]}}}],["acknowledg",{"_index":150,"t":{"233":{"position":[[0,16]]},"280":{"position":[[0,15]]},"786":{"position":[[0,15]]},"850":{"position":[[0,16]]},"1164":{"position":[[0,16]]}}}],["action",{"_index":385,"t":{"562":{"position":[[5,7]]},"564":{"position":[[10,7]]}}}],["acz",{"_index":14,"t":{"27":{"position":[[28,5]]},"1430":{"position":[[26,5]]}}}],["ad",{"_index":369,"t":{"538":{"position":[[10,6]]}}}],["adapt",{"_index":86,"t":{"134":{"position":[[7,8]]},"1033":{"position":[[3,8]]}}}],["addit",{"_index":496,"t":{"801":{"position":[[0,10]]}}}],["address",{"_index":396,"t":{"580":{"position":[[22,9]]},"592":{"position":[[14,9]]}}}],["advantag",{"_index":372,"t":{"540":{"position":[[4,10]]}}}],["aleo",{"_index":652,"t":{"1237":{"position":[[3,6]]}}}],["ambient",{"_index":431,"t":{"638":{"position":[[8,7]]}}}],["analysi",{"_index":426,"t":{"634":{"position":[[27,8]]},"726":{"position":[[12,8]]},"728":{"position":[[9,8]]},"730":{"position":[[8,8]]},"1190":{"position":[[20,8]]},"1220":{"position":[[13,8]]}}}],["anonym",{"_index":333,"t":{"504":{"position":[[14,9]]},"634":{"position":[[17,9]]},"1172":{"position":[[45,9]]},"1178":{"position":[[0,9]]},"1180":{"position":[[0,9]]}}}],["anounc",{"_index":43,"t":{"77":{"position":[[18,11]]}}}],["app",{"_index":532,"t":{"929":{"position":[[7,3]]},"1158":{"position":[[16,4]]}}}],["appetit",{"_index":558,"t":{"1003":{"position":[[0,8]]}}}],["appli",{"_index":11,"t":{"27":{"position":[[0,7]]},"93":{"position":[[4,8]]},"1430":{"position":[[0,7]]}}}],["applic",{"_index":425,"t":{"630":{"position":[[27,12]]}}}],["approach",{"_index":363,"t":{"532":{"position":[[33,8]]}}}],["approv",{"_index":173,"t":{"268":{"position":[[20,9]]}}}],["architectur",{"_index":259,"t":{"425":{"position":[[34,12]]},"427":{"position":[[26,13]]},"443":{"position":[[21,12]]},"451":{"position":[[15,12]]},"496":{"position":[[43,12]]},"536":{"position":[[31,12]]}}}],["architecture'",{"_index":377,"t":{"546":{"position":[[3,14]]}}}],["assur",{"_index":8,"t":{"15":{"position":[[8,9]]},"1424":{"position":[[8,9]]}}}],["attack",{"_index":595,"t":{"1083":{"position":[[0,7]]},"1184":{"position":[[0,8]]},"1190":{"position":[[0,6]]},"1196":{"position":[[7,6]]}}}],["avail",{"_index":575,"t":{"1037":{"position":[[14,12]]},"1150":{"position":[[10,9]]}}}],["b",{"_index":376,"t":{"544":{"position":[[0,2]]},"550":{"position":[[0,2]]},"570":{"position":[[0,2]]},"580":{"position":[[0,2]]},"1148":{"position":[[28,1]]}}}],["background",{"_index":27,"t":{"62":{"position":[[0,10]]},"108":{"position":[[0,10]]},"335":{"position":[[0,10]]},"823":{"position":[[0,10]]},"910":{"position":[[18,10]]},"943":{"position":[[0,10]]},"1073":{"position":[[4,10]]},"1131":{"position":[[0,10]]},"1144":{"position":[[0,11]]}}}],["bandwidth",{"_index":199,"t":{"313":{"position":[[7,9]]},"487":{"position":[[23,9]]},"644":{"position":[[20,9]]}}}],["bare",{"_index":465,"t":{"732":{"position":[[4,4]]}}}],["base",{"_index":215,"t":{"345":{"position":[[4,5]]},"443":{"position":[[15,5]]},"600":{"position":[[7,5]]},"625":{"position":[[4,5]]},"1069":{"position":[[4,5]]},"1190":{"position":[[7,5]]}}}],["baselin",{"_index":559,"t":{"1007":{"position":[[0,8]]}}}],["basic",{"_index":166,"t":{"262":{"position":[[0,5]]},"264":{"position":[[0,5]]},"483":{"position":[[0,5]]},"487":{"position":[[0,5]]},"742":{"position":[[0,5]]}}}],["beat",{"_index":291,"t":{"463":{"position":[[35,4]]}}}],["begin",{"_index":252,"t":{"411":{"position":[[4,9]]}}}],["behavior",{"_index":566,"t":{"1017":{"position":[[18,8]]}}}],["behind",{"_index":132,"t":{"203":{"position":[[20,6]]},"427":{"position":[[10,6]]}}}],["bench",{"_index":455,"t":{"692":{"position":[[5,5]]}}}],["benchmark",{"_index":65,"t":{"95":{"position":[[0,9]]},"112":{"position":[[18,10]]},"114":{"position":[[0,12]]}}}],["benefit",{"_index":242,"t":{"382":{"position":[[14,8]]}}}],["better",{"_index":222,"t":{"357":{"position":[[0,6]]},"461":{"position":[[11,6]]},"1023":{"position":[[10,6]]}}}],["between",{"_index":510,"t":{"846":{"position":[[11,7]]}}}],["bloom",{"_index":321,"t":{"498":{"position":[[25,5]]},"854":{"position":[[16,5]]},"856":{"position":[[0,5]]},"864":{"position":[[15,5]]},"872":{"position":[[0,5]]}}}],["break",{"_index":553,"t":{"995":{"position":[[3,8]]}}}],["breakdown",{"_index":549,"t":{"983":{"position":[[13,9]]}}}],["bridg",{"_index":569,"t":{"1021":{"position":[[22,6]]}}}],["brief",{"_index":527,"t":{"910":{"position":[[0,5]]}}}],["briefli",{"_index":171,"t":{"268":{"position":[[0,7]]},"299":{"position":[[0,7]]}}}],["browser",{"_index":415,"t":{"607":{"position":[[35,7]]},"663":{"position":[[15,7]]}}}],["build",{"_index":81,"t":{"126":{"position":[[4,5]]},"632":{"position":[[0,8]]}}}],["busi",{"_index":629,"t":{"1156":{"position":[[23,8]]}}}],["c",{"_index":380,"t":{"552":{"position":[[0,2]]},"574":{"position":[[0,2]]},"596":{"position":[[0,2]]}}}],["cach",{"_index":568,"t":{"1019":{"position":[[22,7]]}}}],["cairo",{"_index":660,"t":{"1247":{"position":[[4,7]]}}}],["calcul",{"_index":307,"t":{"487":{"position":[[6,12]]}}}],["candid",{"_index":680,"t":{"1277":{"position":[[10,11]]},"1279":{"position":[[31,10]]}}}],["capabl",{"_index":573,"t":{"1033":{"position":[[22,12]]},"1091":{"position":[[0,10]]}}}],["capac",{"_index":228,"t":{"361":{"position":[[15,8]]}}}],["case",{"_index":368,"t":{"538":{"position":[[4,5]]},"578":{"position":[[4,5]]},"925":{"position":[[4,5]]},"1382":{"position":[[19,5]]}}}],["caveat",{"_index":181,"t":{"288":{"position":[[0,7]]}}}],["cellular",{"_index":144,"t":{"223":{"position":[[7,8]]}}}],["ceno",{"_index":668,"t":{"1255":{"position":[[4,6]]}}}],["censorship",{"_index":633,"t":{"1182":{"position":[[0,10]]},"1342":{"position":[[4,10]]}}}],["central",{"_index":473,"t":{"756":{"position":[[0,11]]}}}],["centric",{"_index":318,"t":{"496":{"position":[[18,7]]},"532":{"position":[[25,7]]}}}],["chain",{"_index":375,"t":{"540":{"position":[[40,5]]}}}],["challeng",{"_index":73,"t":{"110":{"position":[[4,9]]},"431":{"position":[[0,10]]}}}],["chang",{"_index":699,"t":{"1332":{"position":[[29,6]]}}}],["chat",{"_index":628,"t":{"1156":{"position":[[7,4]]}}}],["chaum",{"_index":520,"t":{"886":{"position":[[0,5]]},"894":{"position":[[0,5]]},"900":{"position":[[0,5]]}}}],["check",{"_index":351,"t":{"520":{"position":[[27,5]]}}}],["choic",{"_index":696,"t":{"1328":{"position":[[8,7]]}}}],["circuit",{"_index":96,"t":{"144":{"position":[[6,7]]},"799":{"position":[[16,7]]},"801":{"position":[[11,7]]}}}],["client",{"_index":101,"t":{"150":{"position":[[16,6]]},"502":{"position":[[30,7]]}}}],["code",{"_index":295,"t":{"467":{"position":[[11,4]]}}}],["collect",{"_index":683,"t":{"1320":{"position":[[16,10]]}}}],["combin",{"_index":517,"t":{"874":{"position":[[0,9]]}}}],["come",{"_index":585,"t":{"1059":{"position":[[0,6]]}}}],["comment",{"_index":504,"t":{"809":{"position":[[0,8]]}}}],["commit",{"_index":60,"t":{"89":{"position":[[12,6]]},"578":{"position":[[58,10]]}}}],["commun",{"_index":154,"t":{"237":{"position":[[26,11]]},"830":{"position":[[19,13]]}}}],["comparison",{"_index":438,"t":{"644":{"position":[[30,10]]},"949":{"position":[[13,10]]},"962":{"position":[[16,10]]}}}],["complex",{"_index":511,"t":{"858":{"position":[[0,10]]},"870":{"position":[[0,10]]}}}],["compon",{"_index":378,"t":{"546":{"position":[[18,10]]},"568":{"position":[[3,10]]},"1142":{"position":[[10,10]]}}}],["comput",{"_index":625,"t":{"1154":{"position":[[0,7]]}}}],["concept",{"_index":458,"t":{"706":{"position":[[9,7]]}}}],["concern",{"_index":267,"t":{"435":{"position":[[13,8]]}}}],["conclus",{"_index":69,"t":{"99":{"position":[[0,10]]},"118":{"position":[[0,10]]},"164":{"position":[[0,10]]},"209":{"position":[[0,10]]},"526":{"position":[[0,10]]},"542":{"position":[[0,10]]},"594":{"position":[[5,10]]},"710":{"position":[[0,10]]},"784":{"position":[[0,10]]},"815":{"position":[[0,10]]},"902":{"position":[[0,10]]},"939":{"position":[[0,10]]},"964":{"position":[[0,11]]},"1095":{"position":[[0,10]]},"1123":{"position":[[0,11]]},"1269":{"position":[[13,11]]}}}],["consid",{"_index":195,"t":{"311":{"position":[[7,11]]},"394":{"position":[[10,10]]}}}],["consider",{"_index":273,"t":{"437":{"position":[[31,15]]}}}],["constraint",{"_index":451,"t":{"688":{"position":[[0,11]]},"801":{"position":[[19,11]]}}}],["construct",{"_index":116,"t":{"178":{"position":[[0,12]]},"516":{"position":[[30,9]]}}}],["consumpt",{"_index":391,"t":{"570":{"position":[[38,11]]},"572":{"position":[[16,11]]}}}],["cont",{"_index":551,"t":{"991":{"position":[[29,6]]}}}],["contact",{"_index":700,"t":{"1334":{"position":[[3,7]]}}}],["context",{"_index":352,"t":{"520":{"position":[[40,7]]}}}],["continu",{"_index":708,"t":{"1356":{"position":[[4,11]]}}}],["contract",{"_index":22,"t":{"49":{"position":[[6,9]]},"558":{"position":[[9,9]]},"1154":{"position":[[20,8]]},"1426":{"position":[[6,9]]}}}],["contribut",{"_index":536,"t":{"937":{"position":[[0,10]]},"1308":{"position":[[7,10]]},"1310":{"position":[[8,10]]}}}],["control",{"_index":640,"t":{"1200":{"position":[[0,10]]}}}],["convers",{"_index":223,"t":{"357":{"position":[[7,14]]}}}],["core",{"_index":564,"t":{"1015":{"position":[[3,4]]}}}],["correl",{"_index":642,"t":{"1204":{"position":[[0,11]]}}}],["coscup",{"_index":439,"t":{"646":{"position":[[9,7]]}}}],["cosmo",{"_index":160,"t":{"245":{"position":[[26,7]]}}}],["cost",{"_index":327,"t":{"500":{"position":[[31,4]]},"702":{"position":[[4,5]]},"780":{"position":[[0,4]]}}}],["countermeasur",{"_index":68,"t":{"97":{"position":[[24,15]]}}}],["counterpoint",{"_index":614,"t":{"1138":{"position":[[0,12]]},"1140":{"position":[[0,12]]}}}],["cpu",{"_index":140,"t":{"221":{"position":[[0,3]]}}}],["crate",{"_index":77,"t":{"114":{"position":[[35,5]]},"524":{"position":[[18,6]]}}}],["creat",{"_index":48,"t":{"81":{"position":[[8,7]]},"89":{"position":[[3,8]]},"425":{"position":[[8,6]]},"578":{"position":[[42,6]]}}}],["creation",{"_index":55,"t":{"85":{"position":[[3,8]]},"433":{"position":[[24,8]]},"441":{"position":[[15,8]]}}}],["credenti",{"_index":107,"t":{"152":{"position":[[29,11]]},"243":{"position":[[16,11]]}}}],["criterion",{"_index":76,"t":{"114":{"position":[[25,9]]}}}],["cross",{"_index":100,"t":{"150":{"position":[[10,5]]}}}],["cryptograph",{"_index":392,"t":{"574":{"position":[[3,13]]}}}],["cryptographi",{"_index":12,"t":{"27":{"position":[[8,12]]},"1430":{"position":[[8,12]]}}}],["cuckoo",{"_index":323,"t":{"498":{"position":[[43,6]]},"854":{"position":[[34,6]]},"866":{"position":[[0,6]]},"872":{"position":[[17,6]]}}}],["current",{"_index":284,"t":{"453":{"position":[[0,7]]},"840":{"position":[[0,7]]},"1049":{"position":[[0,7]]}}}],["d",{"_index":381,"t":{"554":{"position":[[0,2]]},"602":{"position":[[0,2]]}}}],["dapp",{"_index":371,"t":{"538":{"position":[[37,5]]}}}],["dappconnect",{"_index":533,"t":{"931":{"position":[[0,12]]}}}],["data",{"_index":145,"t":{"223":{"position":[[16,4]]},"475":{"position":[[18,5]]},"653":{"position":[[4,4]]},"657":{"position":[[4,4]]},"678":{"position":[[0,4]]},"1320":{"position":[[54,4]]},"1322":{"position":[[38,4]]},"1326":{"position":[[13,4]]}}}],["de",{"_index":30,"t":{"67":{"position":[[0,2]]}}}],["deal",{"_index":91,"t":{"140":{"position":[[0,7]]}}}],["debug",{"_index":293,"t":{"465":{"position":[[0,9]]}}}],["decentr",{"_index":424,"t":{"630":{"position":[[13,13]]},"828":{"position":[[8,16]]}}}],["decentralis",{"_index":704,"t":{"1352":{"position":[[5,16]]}}}],["decoupl",{"_index":373,"t":{"540":{"position":[[15,10]]}}}],["defi",{"_index":279,"t":{"447":{"position":[[23,4]]}}}],["defin",{"_index":346,"t":{"516":{"position":[[19,6]]}}}],["definit",{"_index":428,"t":{"634":{"position":[[44,11]]},"673":{"position":[[0,11]]},"1172":{"position":[[9,12]]}}}],["delet",{"_index":487,"t":{"780":{"position":[[43,8]]}}}],["deliv",{"_index":552,"t":{"993":{"position":[[20,7]]}}}],["depend",{"_index":133,"t":{"205":{"position":[[8,7]]}}}],["descript",{"_index":230,"t":{"371":{"position":[[8,11]]}}}],["design",{"_index":197,"t":{"311":{"position":[[44,6]]},"445":{"position":[[29,6]]},"506":{"position":[[45,6]]},"544":{"position":[[3,6]]},"981":{"position":[[14,6]]}}}],["detail",{"_index":175,"t":{"270":{"position":[[10,7]]}}}],["detect",{"_index":480,"t":{"774":{"position":[[5,9]]},"805":{"position":[[34,9]]}}}],["develop",{"_index":289,"t":{"461":{"position":[[58,11]]}}}],["devic",{"_index":111,"t":{"162":{"position":[[0,6]]},"485":{"position":[[15,7]]},"510":{"position":[[0,6]]},"830":{"position":[[0,6]]},"1121":{"position":[[29,6]]}}}],["dht",{"_index":590,"t":{"1073":{"position":[[0,3]]},"1083":{"position":[[11,4]]}}}],["differ",{"_index":364,"t":{"534":{"position":[[9,7]]},"846":{"position":[[0,10]]}}}],["diffi",{"_index":600,"t":{"1103":{"position":[[4,6]]}}}],["disclaim",{"_index":714,"t":{"1390":{"position":[[3,11]]}}}],["discoveri",{"_index":162,"t":{"247":{"position":[[16,9]]},"343":{"position":[[8,9]]},"345":{"position":[[10,9]]},"349":{"position":[[10,9]]},"363":{"position":[[13,9]]},"625":{"position":[[10,9]]},"638":{"position":[[21,9]]},"1069":{"position":[[10,9]]},"1071":{"position":[[0,9]]},"1075":{"position":[[12,9]]},"1079":{"position":[[26,9]]},"1081":{"position":[[13,9]]},"1087":{"position":[[29,9]]}}}],["discuss",{"_index":544,"t":{"960":{"position":[[0,10]]}}}],["discv4",{"_index":255,"t":{"417":{"position":[[0,6]]}}}],["discv5",{"_index":256,"t":{"419":{"position":[[0,6]]},"617":{"position":[[19,6]]},"621":{"position":[[17,6]]},"1081":{"position":[[0,6]]}}}],["disput",{"_index":720,"t":{"1406":{"position":[[4,8]]}}}],["dissemin",{"_index":337,"t":{"506":{"position":[[64,13]]}}}],["distribut",{"_index":16,"t":{"39":{"position":[[0,11]]},"413":{"position":[[0,11]]},"1422":{"position":[[0,11]]}}}],["dn",{"_index":214,"t":{"345":{"position":[[0,3]]},"625":{"position":[[0,3]]},"1069":{"position":[[0,3]]}}}],["do",{"_index":151,"t":{"237":{"position":[[0,3]]},"504":{"position":[[24,3]]},"722":{"position":[[20,3]]},"724":{"position":[[0,3]]},"1206":{"position":[[0,3]]}}}],["doc",{"_index":713,"t":{"1378":{"position":[[0,4]]}}}],["dogfood",{"_index":530,"t":{"921":{"position":[[20,10]]}}}],["doubl",{"_index":501,"t":{"805":{"position":[[17,6]]}}}],["drawback",{"_index":67,"t":{"97":{"position":[[10,9]]}}}],["dst",{"_index":19,"t":{"39":{"position":[[28,5]]},"1422":{"position":[[28,5]]}}}],["dual",{"_index":261,"t":{"427":{"position":[[21,4]]}}}],["duplic",{"_index":244,"t":{"392":{"position":[[26,10]]}}}],["e",{"_index":383,"t":{"556":{"position":[[0,2]]},"598":{"position":[[0,2]]}}}],["econom",{"_index":5,"t":{"9":{"position":[[6,9]]},"609":{"position":[[23,8]]},"762":{"position":[[10,8]]},"1420":{"position":[[6,9]]}}}],["effect",{"_index":484,"t":{"780":{"position":[[5,9]]}}}],["effici",{"_index":328,"t":{"500":{"position":[[36,9]]}}}],["elimin",{"_index":237,"t":{"378":{"position":[[3,11]]}}}],["emerg",{"_index":271,"t":{"437":{"position":[[0,8]]}}}],["emit",{"_index":42,"t":{"77":{"position":[[3,8]]}}}],["end",{"_index":611,"t":{"1132":{"position":[[28,3]]}}}],["ephemer",{"_index":402,"t":{"590":{"position":[[3,9]]},"1105":{"position":[[0,9]]}}}],["epoch",{"_index":498,"t":{"803":{"position":[[26,5]]}}}],["error",{"_index":290,"t":{"463":{"position":[[0,5]]}}}],["estim",{"_index":593,"t":{"1077":{"position":[[24,10]]}}}],["etc",{"_index":500,"t":{"803":{"position":[[50,5]]},"805":{"position":[[58,5]]},"1039":{"position":[[63,4]]}}}],["ethereum",{"_index":159,"t":{"245":{"position":[[14,8]]},"611":{"position":[[24,8]]},"646":{"position":[[34,8]]},"931":{"position":[[13,8]]},"987":{"position":[[9,8]]},"989":{"position":[[3,8]]},"991":{"position":[[3,8]]},"1144":{"position":[[12,8]]}}}],["ethic",{"_index":129,"t":{"202":{"position":[[0,6]]},"205":{"position":[[19,6]]},"642":{"position":[[16,6]]}}}],["european",{"_index":693,"t":{"1326":{"position":[[30,8]]}}}],["evalu",{"_index":311,"t":{"492":{"position":[[21,10]]}}}],["event",{"_index":457,"t":{"704":{"position":[[0,6]]}}}],["evolut",{"_index":336,"t":{"506":{"position":[[24,9]]}}}],["evolv",{"_index":164,"t":{"251":{"position":[[4,8]]}}}],["exampl",{"_index":170,"t":{"266":{"position":[[14,7]]},"860":{"position":[[0,7]]},"868":{"position":[[0,7]]},"935":{"position":[[5,8]]}}}],["exceed",{"_index":488,"t":{"782":{"position":[[0,9]]}}}],["except",{"_index":292,"t":{"463":{"position":[[40,10]]}}}],["exchang",{"_index":217,"t":{"347":{"position":[[15,8]]},"636":{"position":[[24,8]]},"1085":{"position":[[5,8]]},"1089":{"position":[[15,8]]},"1103":{"position":[[23,8]]}}}],["execut",{"_index":366,"t":{"534":{"position":[[35,9]]},"554":{"position":[[3,9]]},"560":{"position":[[11,9]]},"566":{"position":[[3,9]]}}}],["exist",{"_index":370,"t":{"538":{"position":[[28,8]]}}}],["experi",{"_index":205,"t":{"327":{"position":[[0,11]]},"401":{"position":[[0,11]]}}}],["exploit",{"_index":136,"t":{"207":{"position":[[31,11]]}}}],["explor",{"_index":314,"t":{"494":{"position":[[0,9]]}}}],["export",{"_index":691,"t":{"1326":{"position":[[3,9]]}}}],["extens",{"_index":120,"t":{"184":{"position":[[0,10]]},"1158":{"position":[[0,10]]}}}],["extern",{"_index":497,"t":{"803":{"position":[[17,8]]},"1188":{"position":[[0,8]]}}}],["f",{"_index":384,"t":{"558":{"position":[[0,2]]},"600":{"position":[[0,2]]}}}],["factor",{"_index":571,"t":{"1029":{"position":[[9,7]]}}}],["fals",{"_index":513,"t":{"862":{"position":[[15,5]]}}}],["far",{"_index":188,"t":{"301":{"position":[[12,3]]},"665":{"position":[[16,3]]}}}],["feasbl",{"_index":139,"t":{"219":{"position":[[0,10]]}}}],["feasibl",{"_index":176,"t":{"272":{"position":[[0,11]]},"274":{"position":[[10,11]]},"276":{"position":[[7,11]]},"617":{"position":[[0,11]]},"651":{"position":[[0,11]]},"776":{"position":[[0,11]]}}}],["fiat",{"_index":521,"t":{"890":{"position":[[4,4]]},"892":{"position":[[33,4]]},"894":{"position":[[40,4]]},"896":{"position":[[20,4]]},"898":{"position":[[31,4]]},"900":{"position":[[33,4]]}}}],["filter",{"_index":322,"t":{"498":{"position":[[31,7],[50,7]]},"854":{"position":[[22,7],[41,7]]},"856":{"position":[[6,7]]},"864":{"position":[[21,6]]},"866":{"position":[[7,7]]},"872":{"position":[[6,7],[24,7]]},"874":{"position":[[10,7]]}}}],["find",{"_index":147,"t":{"227":{"position":[[0,7]]},"329":{"position":[[0,8]]},"405":{"position":[[0,8]]},"1267":{"position":[[11,8]]}}}],["fix",{"_index":440,"t":{"649":{"position":[[0,6]]}}}],["flexibl",{"_index":326,"t":{"500":{"position":[[18,8]]}}}],["floodsub",{"_index":562,"t":{"1011":{"position":[[3,8]]}}}],["flow",{"_index":32,"t":{"71":{"position":[[0,4]]},"142":{"position":[[19,4]]},"264":{"position":[[6,4]]},"677":{"position":[[0,4]]},"764":{"position":[[0,4]]}}}],["footnot",{"_index":285,"t":{"457":{"position":[[0,9]]},"790":{"position":[[0,9]]},"1168":{"position":[[0,9]]}}}],["format",{"_index":294,"t":{"467":{"position":[[0,10]]},"678":{"position":[[5,6]]}}}],["forward",{"_index":3,"t":{"7":{"position":[[8,7]]},"13":{"position":[[8,7]]},"19":{"position":[[8,7]]},"25":{"position":[[8,7]]},"31":{"position":[[8,7]]},"37":{"position":[[8,7]]},"43":{"position":[[8,7]]},"53":{"position":[[8,7]]},"834":{"position":[[7,7]]},"1392":{"position":[[3,7]]}}}],["framework",{"_index":281,"t":{"447":{"position":[[64,9]]},"1107":{"position":[[19,9]]}}}],["friendli",{"_index":406,"t":{"598":{"position":[[13,8]]}}}],["full",{"_index":576,"t":{"1039":{"position":[[25,4]]}}}],["function",{"_index":394,"t":{"576":{"position":[[8,9]]},"888":{"position":[[5,9]]}}}],["further",{"_index":596,"t":{"1087":{"position":[[0,7]]}}}],["futur",{"_index":70,"t":{"101":{"position":[[0,6]]},"353":{"position":[[0,6]]},"489":{"position":[[0,6]]},"602":{"position":[[3,6]]},"628":{"position":[[4,6]]},"682":{"position":[[0,6]]},"708":{"position":[[0,6]]},"736":{"position":[[0,6]]},"784":{"position":[[15,6]]},"817":{"position":[[0,6]]},"848":{"position":[[15,6]]},"966":{"position":[[0,6]]},"1095":{"position":[[15,6]]},"1125":{"position":[[0,6]]},"1208":{"position":[[12,6]]}}}],["ga",{"_index":44,"t":{"77":{"position":[[30,4]]},"702":{"position":[[0,3]]}}}],["gener",{"_index":148,"t":{"231":{"position":[[0,7]]},"278":{"position":[[0,7]]},"560":{"position":[[3,7]]},"570":{"position":[[24,10]]}}}],["get",{"_index":357,"t":{"522":{"position":[[18,7]]}}}],["go",{"_index":343,"t":{"510":{"position":[[30,2]]}}}],["goal",{"_index":182,"t":{"290":{"position":[[0,5]]},"425":{"position":[[0,4]]},"433":{"position":[[0,4]]},"441":{"position":[[0,4]]},"443":{"position":[[0,4]]},"445":{"position":[[0,4]]},"447":{"position":[[0,4]]},"449":{"position":[[22,4]]},"915":{"position":[[0,5]]},"981":{"position":[[21,5]]}}}],["goal1",{"_index":190,"t":{"309":{"position":[[0,6]]}}}],["goal2",{"_index":194,"t":{"311":{"position":[[0,6]]}}}],["goal3",{"_index":198,"t":{"313":{"position":[[0,6]]}}}],["goal4",{"_index":201,"t":{"315":{"position":[[0,6]]}}}],["goal5",{"_index":204,"t":{"317":{"position":[[0,6]]}}}],["gossipsub",{"_index":216,"t":{"347":{"position":[[0,9]]},"397":{"position":[[0,9]]},"399":{"position":[[0,9]]},"506":{"position":[[0,9]]},"1025":{"position":[[3,9]]},"1089":{"position":[[0,9]]}}}],["govern",{"_index":719,"t":{"1404":{"position":[[3,9]]}}}],["group",{"_index":39,"t":{"75":{"position":[[3,5]]},"77":{"position":[[12,5]]}}}],["guarante",{"_index":226,"t":{"357":{"position":[[37,10]]}}}],["guid",{"_index":468,"t":{"734":{"position":[[10,5]]}}}],["handl",{"_index":202,"t":{"315":{"position":[[7,8]]},"463":{"position":[[6,8]]}}}],["handshak",{"_index":430,"t":{"636":{"position":[[6,10]]},"1113":{"position":[[16,10]]},"1115":{"position":[[9,9]]},"1117":{"position":[[8,9]]},"1119":{"position":[[18,10]]}}}],["harmon",{"_index":262,"t":{"429":{"position":[[0,11]]}}}],["hash",{"_index":253,"t":{"413":{"position":[[12,4]]},"576":{"position":[[3,4]]},"578":{"position":[[34,4]]},"888":{"position":[[0,4]]}}}],["head",{"_index":24,"t":{"55":{"position":[[0,7]]}}}],["hellman",{"_index":601,"t":{"1103":{"position":[[11,7]]}}}],["heterogen",{"_index":155,"t":{"239":{"position":[[2,13]]},"311":{"position":[[19,13]]},"628":{"position":[[58,13]]}}}],["heurist",{"_index":523,"t":{"890":{"position":[[16,9]]},"896":{"position":[[32,9]]},"898":{"position":[[43,9]]},"900":{"position":[[45,9]]}}}],["hide",{"_index":340,"t":{"508":{"position":[[30,6]]}}}],["high",{"_index":555,"t":{"995":{"position":[[33,4]]},"1037":{"position":[[9,4]]}}}],["highlight",{"_index":1,"t":{"5":{"position":[[0,10]]},"11":{"position":[[0,10]]},"17":{"position":[[0,10]]},"23":{"position":[[0,10]]},"29":{"position":[[0,10]]},"35":{"position":[[0,10]]},"41":{"position":[[0,10]]},"47":{"position":[[0,10]]},"51":{"position":[[0,10]]}}}],["hire",{"_index":557,"t":{"997":{"position":[[11,7]]}}}],["histor",{"_index":567,"t":{"1019":{"position":[[3,10]]}}}],["histori",{"_index":528,"t":{"910":{"position":[[6,7]]}}}],["host",{"_index":374,"t":{"540":{"position":[[35,4]]}}}],["huilong",{"_index":529,"t":{"921":{"position":[[8,7]]}}}],["hybrid",{"_index":365,"t":{"534":{"position":[[28,6]]}}}],["ident",{"_index":618,"t":{"1146":{"position":[[25,8]]}}}],["ii",{"_index":398,"t":{"584":{"position":[[0,3]]},"1342":{"position":[[0,3]]}}}],["iii",{"_index":399,"t":{"586":{"position":[[0,4]]},"1344":{"position":[[0,4]]}}}],["implement",{"_index":277,"t":{"443":{"position":[[34,14]]},"500":{"position":[[46,14]]},"524":{"position":[[25,14]]},"807":{"position":[[4,14]]},"919":{"position":[[0,15]]},"1053":{"position":[[0,14]]},"1380":{"position":[[0,15]]}}}],["import",{"_index":74,"t":{"112":{"position":[[4,10]]}}}],["improp",{"_index":525,"t":{"896":{"position":[[0,8]]}}}],["improv",{"_index":209,"t":{"339":{"position":[[3,12]]},"341":{"position":[[3,12]]},"361":{"position":[[0,8]]},"373":{"position":[[9,12]]},"506":{"position":[[10,13]]},"945":{"position":[[12,12]]}}}],["incent",{"_index":474,"t":{"762":{"position":[[19,9]]}}}],["incentiv",{"_index":157,"t":{"241":{"position":[[14,15]]},"359":{"position":[[9,15]]},"628":{"position":[[37,16]]},"1039":{"position":[[3,11]]}}}],["inclus",{"_index":706,"t":{"1354":{"position":[[6,11]]}}}],["indemn",{"_index":718,"t":{"1400":{"position":[[3,9]]}}}],["industri",{"_index":126,"t":{"198":{"position":[[16,8]]},"642":{"position":[[48,8]]}}}],["inform",{"_index":631,"t":{"1172":{"position":[[0,8]]},"1279":{"position":[[12,11]]},"1334":{"position":[[11,11]]}}}],["infrastructur",{"_index":84,"t":{"126":{"position":[[29,15]]},"128":{"position":[[5,14]]},"130":{"position":[[26,14]]},"630":{"position":[[44,15]]},"632":{"position":[[28,14]]}}}],["initi",{"_index":40,"t":{"75":{"position":[[9,14]]}}}],["input",{"_index":495,"t":{"799":{"position":[[24,6]]}}}],["insert",{"_index":456,"t":{"698":{"position":[[0,9]]},"780":{"position":[[29,9]]}}}],["insight",{"_index":679,"t":{"1269":{"position":[[0,8]]}}}],["integr",{"_index":31,"t":{"69":{"position":[[5,11]]},"439":{"position":[[15,12]]},"447":{"position":[[8,11]]},"1015":{"position":[[8,11]]},"1382":{"position":[[0,12]]}}}],["intellectu",{"_index":716,"t":{"1394":{"position":[[3,12]]}}}],["interact",{"_index":89,"t":{"136":{"position":[[16,12]]},"445":{"position":[[17,11]]},"680":{"position":[[0,11]]}}}],["interest",{"_index":565,"t":{"1017":{"position":[[9,8]]}}}],["intern",{"_index":134,"t":{"207":{"position":[[0,13]]},"1186":{"position":[[0,8]]}}}],["interoper",{"_index":212,"t":{"341":{"position":[[19,16]]}}}],["interpol",{"_index":461,"t":{"720":{"position":[[22,13]]}}}],["intregr",{"_index":117,"t":{"180":{"position":[[12,10]]}}}],["intro",{"_index":80,"t":{"122":{"position":[[0,5]]},"975":{"position":[[7,5]]}}}],["introduc",{"_index":184,"t":{"296":{"position":[[0,11]]},"532":{"position":[[0,11]]},"640":{"position":[[0,11]]}}}],["introduct",{"_index":26,"t":{"60":{"position":[[0,12]]},"172":{"position":[[0,12]]},"284":{"position":[[0,12]]},"307":{"position":[[0,12]]},"423":{"position":[[0,12]]},"514":{"position":[[0,12]]},"686":{"position":[[0,12]]},"716":{"position":[[0,12]]},"750":{"position":[[0,12]]},"794":{"position":[[0,12]]},"880":{"position":[[0,12]]},"908":{"position":[[0,12]]},"972":{"position":[[3,12]]},"1101":{"position":[[0,12]]}}}],["involv",{"_index":506,"t":{"832":{"position":[[4,8]]}}}],["issu",{"_index":236,"t":{"376":{"position":[[24,6]]},"776":{"position":[[21,6]]}}}],["iter",{"_index":539,"t":{"950":{"position":[[0,9]]},"952":{"position":[[0,9]]},"954":{"position":[[0,9]]},"956":{"position":[[0,9]]},"958":{"position":[[0,9]]}}}],["iv",{"_index":400,"t":{"588":{"position":[[0,3]]},"1346":{"position":[[0,3]]}}}],["iwant",{"_index":243,"t":{"382":{"position":[[28,5]]}}}],["ix",{"_index":707,"t":{"1356":{"position":[[0,3]]}}}],["join",{"_index":35,"t":{"73":{"position":[[11,5]]},"79":{"position":[[8,5]]}}}],["jolt",{"_index":650,"t":{"1233":{"position":[[3,6]]}}}],["journey",{"_index":547,"t":{"974":{"position":[[21,7]]}}}],["js",{"_index":342,"t":{"510":{"position":[[18,2]]},"607":{"position":[[11,2]]}}}],["k1k1",{"_index":604,"t":{"1115":{"position":[[4,4]]}}}],["kademlia",{"_index":254,"t":{"415":{"position":[[0,8]]},"621":{"position":[[5,8]]}}}],["kernel",{"_index":276,"t":{"443":{"position":[[8,6]]}}}],["key",{"_index":49,"t":{"81":{"position":[[20,3]]},"83":{"position":[[31,3]]},"540":{"position":[[0,3]]},"580":{"position":[[3,3]]},"582":{"position":[[12,3]]},"584":{"position":[[12,4]]},"586":{"position":[[12,4]]},"588":{"position":[[12,3]]},"590":{"position":[[13,3]]},"636":{"position":[[20,3]]},"1103":{"position":[[19,3]]},"1105":{"position":[[28,4]]}}}],["knowledg",{"_index":313,"t":{"492":{"position":[[37,9]]},"494":{"position":[[54,9]]},"552":{"position":[[14,9]]}}}],["known",{"_index":207,"t":{"337":{"position":[[19,5]]}}}],["larg",{"_index":203,"t":{"315":{"position":[[16,5]]},"374":{"position":[[32,5]]}}}],["latenc",{"_index":192,"t":{"309":{"position":[[11,7]]}}}],["later",{"_index":624,"t":{"1150":{"position":[[39,5]]}}}],["law",{"_index":130,"t":{"202":{"position":[[14,3]]},"203":{"position":[[4,3]]},"205":{"position":[[4,3]]},"207":{"position":[[14,3]]},"1404":{"position":[[13,3]]}}}],["layer",{"_index":225,"t":{"357":{"position":[[31,5]]},"828":{"position":[[0,5]]}}}],["leav",{"_index":454,"t":{"690":{"position":[[43,6]]},"797":{"position":[[16,6]]}}}],["level",{"_index":556,"t":{"995":{"position":[[38,5]]}}}],["leverag",{"_index":339,"t":{"508":{"position":[[19,10]]}}}],["liabil",{"_index":717,"t":{"1398":{"position":[[17,9]]}}}],["liberti",{"_index":702,"t":{"1340":{"position":[[3,7]]}}}],["libp2p",{"_index":561,"t":{"1009":{"position":[[18,6]]},"1021":{"position":[[15,6]]}}}],["librari",{"_index":360,"t":{"524":{"position":[[10,7]]}}}],["lifecycl",{"_index":390,"t":{"570":{"position":[[8,10]]}}}],["light",{"_index":330,"t":{"502":{"position":[[24,5]]},"1039":{"position":[[15,5]]}}}],["limit",{"_index":169,"t":{"266":{"position":[[5,8]]},"504":{"position":[[49,8]]},"651":{"position":[[34,8]]},"762":{"position":[[58,8]]},"1320":{"position":[[6,5]]},"1398":{"position":[[3,10]]}}}],["link",{"_index":698,"t":{"1330":{"position":[[15,5]]},"1396":{"position":[[23,5]]}}}],["list",{"_index":589,"t":{"1067":{"position":[[12,5]]}}}],["log",{"_index":445,"t":{"653":{"position":[[28,3]]},"671":{"position":[[7,3]]}}}],["look",{"_index":2,"t":{"7":{"position":[[0,7]]},"13":{"position":[[0,7]]},"19":{"position":[[0,7]]},"25":{"position":[[0,7]]},"31":{"position":[[0,7]]},"37":{"position":[[0,7]]},"43":{"position":[[0,7]]},"53":{"position":[[0,7]]},"1392":{"position":[[11,7]]}}}],["low",{"_index":191,"t":{"309":{"position":[[7,3]]}}}],["lurk",{"_index":664,"t":{"1251":{"position":[[4,6]]}}}],["machin",{"_index":266,"t":{"433":{"position":[[16,7]]},"492":{"position":[[55,8]]},"494":{"position":[[72,9]]},"552":{"position":[[32,8]]},"1283":{"position":[[0,7]]}}}],["maintain",{"_index":477,"t":{"768":{"position":[[0,11]]}}}],["malici",{"_index":460,"t":{"720":{"position":[[0,9]]}}}],["manag",{"_index":389,"t":{"566":{"position":[[32,10]]},"580":{"position":[[7,10]]},"1121":{"position":[[8,10]]}}}],["mani",{"_index":508,"t":{"842":{"position":[[4,4]]}}}],["matrix",{"_index":345,"t":{"516":{"position":[[4,7]]},"520":{"position":[[11,6]]},"522":{"position":[[37,6]]}}}],["matter",{"_index":643,"t":{"1216":{"position":[[10,6]]}}}],["maxim",{"_index":241,"t":{"382":{"position":[[3,10]]}}}],["md",{"_index":344,"t":{"516":{"position":[[0,3]]},"520":{"position":[[7,3]]}}}],["mdsecheck",{"_index":355,"t":{"522":{"position":[[0,9]]},"524":{"position":[[0,9]]}}}],["mean",{"_index":472,"t":{"752":{"position":[[11,4]]}}}],["measur",{"_index":688,"t":{"1324":{"position":[[12,8]]}}}],["mechan",{"_index":409,"t":{"600":{"position":[[29,9]]},"636":{"position":[[33,9]]},"720":{"position":[[36,9]]}}}],["member",{"_index":486,"t":{"780":{"position":[[22,6]]}}}],["membership",{"_index":119,"t":{"182":{"position":[[9,10]]},"498":{"position":[[9,10]]},"768":{"position":[[16,10]]},"797":{"position":[[34,10]]},"854":{"position":[[0,10]]}}}],["memori",{"_index":141,"t":{"221":{"position":[[6,6]]},"461":{"position":[[37,7]]}}}],["merkl",{"_index":115,"t":{"176":{"position":[[0,6]]},"180":{"position":[[0,6]]},"184":{"position":[[14,6]]},"186":{"position":[[7,6]]},"768":{"position":[[27,6]]},"797":{"position":[[45,6]]}}}],["messag",{"_index":61,"t":{"89":{"position":[[19,7]]},"91":{"position":[[12,8]]},"93":{"position":[[21,7]]},"315":{"position":[[22,8]]},"374":{"position":[[38,8]]},"380":{"position":[[3,7]]},"382":{"position":[[34,8]]},"392":{"position":[[0,7]]},"506":{"position":[[56,7]]},"611":{"position":[[33,9]]},"646":{"position":[[43,9]]},"756":{"position":[[12,9]]},"782":{"position":[[14,9]]},"931":{"position":[[22,9]]},"987":{"position":[[18,9]]},"989":{"position":[[12,9]]},"991":{"position":[[12,9]]},"1019":{"position":[[14,7]]},"1109":{"position":[[0,7]]},"1152":{"position":[[0,9]]},"1202":{"position":[[10,8]]}}}],["metadata",{"_index":463,"t":{"724":{"position":[[25,8]]}}}],["method",{"_index":356,"t":{"522":{"position":[[10,7]]}}}],["methodolog",{"_index":537,"t":{"947":{"position":[[0,11]]},"1218":{"position":[[4,11]]}}}],["metric",{"_index":452,"t":{"690":{"position":[[0,7]]},"694":{"position":[[0,7]]}}}],["miden",{"_index":654,"t":{"1241":{"position":[[4,7]]}}}],["mini",{"_index":630,"t":{"1158":{"position":[[11,4]]}}}],["minim",{"_index":232,"t":{"374":{"position":[[3,10]]},"479":{"position":[[0,7]]}}}],["minimium",{"_index":301,"t":{"481":{"position":[[9,8]]}}}],["minimum",{"_index":466,"t":{"732":{"position":[[9,7]]}}}],["miss",{"_index":587,"t":{"1061":{"position":[[16,7]]}}}],["mitig",{"_index":152,"t":{"237":{"position":[[4,10]]},"376":{"position":[[3,10]]}}}],["ml",{"_index":28,"t":{"63":{"position":[[0,3]]},"67":{"position":[[3,3]]}}}],["mobil",{"_index":447,"t":{"657":{"position":[[18,6]]}}}],["mobilephon",{"_index":298,"t":{"477":{"position":[[4,13]]}}}],["mode",{"_index":186,"t":{"299":{"position":[[16,4]]}}}],["model",{"_index":180,"t":{"286":{"position":[[32,5]]},"292":{"position":[[0,5]]},"1134":{"position":[[25,5]]}}}],["modif",{"_index":493,"t":{"797":{"position":[[0,12]]},"799":{"position":[[0,12]]},"803":{"position":[[0,13]]},"805":{"position":[[0,13]]},"1402":{"position":[[3,13]]}}}],["more",{"_index":535,"t":{"935":{"position":[[0,4]]}}}],["mostli",{"_index":305,"t":{"485":{"position":[[0,6]]}}}],["motiv",{"_index":137,"t":{"215":{"position":[[0,10]]},"257":{"position":[[0,10]]},"297":{"position":[[0,10]]},"369":{"position":[[0,10]]},"471":{"position":[[8,10]]}}}],["motivit",{"_index":189,"t":{"305":{"position":[[0,12]]}}}],["move",{"_index":507,"t":{"834":{"position":[[0,6]]},"1009":{"position":[[10,4]]}}}],["mpc",{"_index":407,"t":{"600":{"position":[[3,3]]}}}],["multi",{"_index":609,"t":{"1121":{"position":[[23,5]]}}}],["multipl",{"_index":490,"t":{"782":{"position":[[33,8]]}}}],["multipli",{"_index":308,"t":{"487":{"position":[[33,10]]}}}],["multipurpos",{"_index":229,"t":{"363":{"position":[[0,12]]}}}],["mvd",{"_index":300,"t":{"481":{"position":[[0,4]]},"680":{"position":[[17,4]]}}}],["nangang",{"_index":583,"t":{"1055":{"position":[[0,7]]}}}],["nat",{"_index":143,"t":{"223":{"position":[[0,3]]},"1093":{"position":[[0,3]]}}}],["need",{"_index":422,"t":{"619":{"position":[[32,5]]},"993":{"position":[[10,6]]}}}],["negoti",{"_index":597,"t":{"1091":{"position":[[11,11]]}}}],["neighbourhood",{"_index":639,"t":{"1198":{"position":[[0,13]]},"1200":{"position":[[11,13]]}}}],["nescienc",{"_index":0,"t":{"3":{"position":[[0,9]]},"492":{"position":[[68,9]]},"496":{"position":[[0,10]]},"508":{"position":[[0,9]]},"536":{"position":[[4,9]]},"556":{"position":[[3,9]]},"568":{"position":[[19,9]]},"576":{"position":[[21,9]]},"580":{"position":[[35,9]]},"592":{"position":[[4,9]]},"602":{"position":[[20,9]]},"1414":{"position":[[0,9]]}}}],["network",{"_index":90,"t":{"138":{"position":[[7,7]]},"140":{"position":[[13,7]]},"239":{"position":[[21,7]]},"245":{"position":[[5,8]]},"251":{"position":[[18,7]]},"506":{"position":[[98,8]]},"518":{"position":[[33,8]]},"628":{"position":[[19,8]]},"949":{"position":[[0,7]]},"962":{"position":[[0,7]]},"1079":{"position":[[36,7]]},"1194":{"position":[[45,7]]}}}],["new",{"_index":185,"t":{"297":{"position":[[17,3]]}}}],["next",{"_index":449,"t":{"667":{"position":[[7,5]]},"848":{"position":[[0,4]]},"1162":{"position":[[7,5]]}}}],["nexu",{"_index":645,"t":{"1223":{"position":[[3,7]]},"1290":{"position":[[3,5]]}}}],["nim",{"_index":20,"t":{"45":{"position":[[0,3]]},"337":{"position":[[3,3]]},"461":{"position":[[0,3]]},"463":{"position":[[18,4]]},"465":{"position":[[13,3]]},"467":{"position":[[19,3]]},"1428":{"position":[[0,3]]}}}],["node",{"_index":87,"t":{"134":{"position":[[16,5]]},"227":{"position":[[10,4]]},"349":{"position":[[5,4]]},"950":{"position":[[16,5]]},"952":{"position":[[16,5]]},"954":{"position":[[16,5]]},"956":{"position":[[16,5]]},"958":{"position":[[17,5]]},"1031":{"position":[[34,5]]},"1033":{"position":[[12,5]]},"1039":{"position":[[30,5]]},"1067":{"position":[[7,4]]}}}],["nois",{"_index":429,"t":{"636":{"position":[[0,5]]},"1107":{"position":[[4,5]]},"1111":{"position":[[4,5]]},"1113":{"position":[[10,5]]}}}],["nonmembership",{"_index":122,"t":{"188":{"position":[[9,13]]}}}],["novanet",{"_index":672,"t":{"1259":{"position":[[4,9]]}}}],["now",{"_index":206,"t":{"337":{"position":[[15,3]]},"1160":{"position":[[13,4]]}}}],["nssa",{"_index":362,"t":{"532":{"position":[[12,5]]},"534":{"position":[[4,4]]},"554":{"position":[[22,4]]},"558":{"position":[[22,4]]},"572":{"position":[[31,4]]},"574":{"position":[[31,4]]},"596":{"position":[[12,4]]}}}],["nullifi",{"_index":335,"t":{"504":{"position":[[58,10]]},"762":{"position":[[67,10]]}}}],["number",{"_index":621,"t":{"1146":{"position":[[58,7]]}}}],["nwaku",{"_index":208,"t":{"337":{"position":[[28,5]]},"640":{"position":[[12,5]]}}}],["o1vm",{"_index":678,"t":{"1265":{"position":[[4,6]]}}}],["object",{"_index":603,"t":{"1111":{"position":[[16,7]]}}}],["observ",{"_index":641,"t":{"1202":{"position":[[0,9]]}}}],["offlin",{"_index":306,"t":{"485":{"position":[[7,7]]}}}],["ola",{"_index":653,"t":{"1239":{"position":[[4,5]]}}}],["open",{"_index":163,"t":{"249":{"position":[[0,4]]},"776":{"position":[[16,4]]},"1350":{"position":[[4,8]]}}}],["oper",{"_index":193,"t":{"309":{"position":[[19,9]]},"355":{"position":[[16,10]]}}}],["opinion",{"_index":432,"t":{"642":{"position":[[0,8]]}}}],["optim",{"_index":200,"t":{"313":{"position":[[17,12]]},"435":{"position":[[0,12]]},"437":{"position":[[13,9]]}}}],["out",{"_index":221,"t":{"355":{"position":[[9,3]]},"1043":{"position":[[0,3]]}}}],["outsid",{"_index":692,"t":{"1326":{"position":[[18,7]]}}}],["overhead",{"_index":482,"t":{"778":{"position":[[8,8]]}}}],["overlay",{"_index":196,"t":{"311":{"position":[[36,7]]},"506":{"position":[[37,7]]}}}],["overview",{"_index":95,"t":{"142":{"position":[[6,8]]},"217":{"position":[[0,8]]},"261":{"position":[[0,8]]},"325":{"position":[[0,8]]},"390":{"position":[[0,8]]},"560":{"position":[[21,8]]},"655":{"position":[[14,8]]},"762":{"position":[[0,9]]},"913":{"position":[[0,8]]}}}],["p",{"_index":353,"t":{"520":{"position":[[51,1]]}}}],["p2p",{"_index":15,"t":{"33":{"position":[[0,3]]},"473":{"position":[[4,4]]},"506":{"position":[[94,3]]},"609":{"position":[[19,3]]},"653":{"position":[[0,3]]},"657":{"position":[[0,3]]},"758":{"position":[[0,3]]},"1418":{"position":[[0,3]]}}}],["packag",{"_index":50,"t":{"81":{"position":[[24,7]]},"83":{"position":[[35,7]]}}}],["packet",{"_index":622,"t":{"1148":{"position":[[10,7]]}}}],["pair",{"_index":112,"t":{"162":{"position":[[7,7]]},"510":{"position":[[7,7]]},"830":{"position":[[7,7]]}}}],["paper",{"_index":711,"t":{"1365":{"position":[[0,6]]}}}],["paramet",{"_index":459,"t":{"718":{"position":[[13,10]]}}}],["part",{"_index":427,"t":{"634":{"position":[[36,4]]},"974":{"position":[[0,4]]},"987":{"position":[[0,4]]}}}],["parti",{"_index":687,"t":{"1322":{"position":[[9,5]]},"1330":{"position":[[9,5]]},"1396":{"position":[[9,5]]}}}],["partial",{"_index":347,"t":{"518":{"position":[[0,7]]}}}],["pattern",{"_index":602,"t":{"1109":{"position":[[8,8]]}}}],["pedersen",{"_index":395,"t":{"578":{"position":[[25,8]]},"886":{"position":[[6,8]]},"894":{"position":[[6,8]]},"900":{"position":[[6,8]]}}}],["peer",{"_index":213,"t":{"343":{"position":[[3,4]]},"347":{"position":[[10,4]]},"638":{"position":[[16,4]]},"778":{"position":[[21,4]]},"1085":{"position":[[0,4]]},"1089":{"position":[[10,4]]}}}],["per",{"_index":483,"t":{"778":{"position":[[17,3]]}}}],["perform",{"_index":211,"t":{"339":{"position":[[33,11]]},"726":{"position":[[0,11]]},"809":{"position":[[12,11]]},"1077":{"position":[[12,11]]}}}],["peril",{"_index":619,"t":{"1146":{"position":[[42,6]]}}}],["permut",{"_index":349,"t":{"518":{"position":[[21,11]]}}}],["persist",{"_index":623,"t":{"1150":{"position":[[24,10]]}}}],["person",{"_index":684,"t":{"1320":{"position":[[45,8]]},"1322":{"position":[[29,8]]}}}],["phase",{"_index":247,"t":{"395":{"position":[[10,5]]}}}],["phone",{"_index":620,"t":{"1146":{"position":[[52,5]]}}}],["piecrust",{"_index":666,"t":{"1253":{"position":[[4,10]]}}}],["plan",{"_index":412,"t":{"602":{"position":[[10,5]]},"615":{"position":[[11,4]]},"848":{"position":[[22,5]]},"1281":{"position":[[8,4]]}}}],["platform",{"_index":367,"t":{"534":{"position":[[45,9]]}}}],["poc",{"_index":580,"t":{"1041":{"position":[[14,3]]},"1057":{"position":[[9,3]]}}}],["polici",{"_index":579,"t":{"1039":{"position":[[54,8]]},"1332":{"position":[[16,6]]}}}],["posit",{"_index":514,"t":{"862":{"position":[[21,9]]},"1194":{"position":[[29,8]]}}}],["possibl",{"_index":231,"t":{"373":{"position":[[0,8]]},"754":{"position":[[0,8]]}}}],["potenti",{"_index":66,"t":{"97":{"position":[[0,9]]}}}],["powdr",{"_index":647,"t":{"1227":{"position":[[3,7]]}}}],["power",{"_index":359,"t":{"522":{"position":[[44,6]]}}}],["pppt",{"_index":249,"t":{"395":{"position":[[27,6]]}}}],["prefac",{"_index":124,"t":{"196":{"position":[[0,7]]}}}],["preliminari",{"_index":681,"t":{"1279":{"position":[[0,11]]}}}],["prelud",{"_index":531,"t":{"927":{"position":[[0,8]]}}}],["prerequisit",{"_index":636,"t":{"1194":{"position":[[0,13]]}}}],["present",{"_index":413,"t":{"607":{"position":[[0,10]]}}}],["preserv",{"_index":280,"t":{"447":{"position":[[53,10]]},"598":{"position":[[30,10]]},"609":{"position":[[8,10]]}}}],["prevent",{"_index":334,"t":{"504":{"position":[[28,10]]},"724":{"position":[[4,10]]}}}],["primit",{"_index":393,"t":{"574":{"position":[[17,10]]}}}],["princip",{"_index":615,"t":{"1142":{"position":[[0,9]]}}}],["principl",{"_index":701,"t":{"1338":{"position":[[0,10]]}}}],["priorit",{"_index":240,"t":{"380":{"position":[[11,14]]}}}],["prioriti",{"_index":471,"t":{"746":{"position":[[19,10]]}}}],["privaci",{"_index":82,"t":{"126":{"position":[[10,7]]},"130":{"position":[[7,7]]},"447":{"position":[[45,7]]},"538":{"position":[[17,7]]},"598":{"position":[[22,7]]},"609":{"position":[[0,7]]},"632":{"position":[[9,7]]},"634":{"position":[[5,7]]},"1172":{"position":[[32,8]]},"1176":{"position":[[0,7]]},"1332":{"position":[[8,7]]},"1346":{"position":[[4,7]]}}}],["privat",{"_index":103,"t":{"152":{"position":[[0,7]]},"550":{"position":[[3,7]]},"584":{"position":[[4,7]]}}}],["probabl",{"_index":512,"t":{"862":{"position":[[0,11]]}}}],["problem",{"_index":138,"t":{"215":{"position":[[11,7]]},"249":{"position":[[5,8]]},"257":{"position":[[11,7]]},"259":{"position":[[8,8]]},"371":{"position":[[0,7]]},"471":{"position":[[0,7]]},"722":{"position":[[7,7]]},"746":{"position":[[0,8]]},"995":{"position":[[19,7]]},"1001":{"position":[[0,7]]}}}],["process",{"_index":387,"t":{"566":{"position":[[13,9]]},"1320":{"position":[[31,10]]},"1322":{"position":[[15,10]]}}}],["progress",{"_index":187,"t":{"301":{"position":[[0,8]]}}}],["project",{"_index":315,"t":{"494":{"position":[[23,8]]},"826":{"position":[[14,7]]},"1220":{"position":[[5,7]]}}}],["promis",{"_index":78,"t":{"116":{"position":[[0,9]]}}}],["proof",{"_index":118,"t":{"182":{"position":[[0,5]]},"188":{"position":[[0,5]]},"441":{"position":[[8,6]]},"502":{"position":[[14,6]]},"706":{"position":[[0,5]]}}}],["properti",{"_index":341,"t":{"508":{"position":[[37,10]]},"1394":{"position":[[16,8]]}}}],["propos",{"_index":57,"t":{"85":{"position":[[22,9]]},"87":{"position":[[14,8]]},"397":{"position":[[15,8]]},"399":{"position":[[15,8]]},"696":{"position":[[0,8]]}}}],["prospect",{"_index":599,"t":{"1095":{"position":[[22,9]]}}}],["protect",{"_index":83,"t":{"126":{"position":[[18,10]]},"130":{"position":[[15,10]]},"351":{"position":[[8,10]]},"609":{"position":[[37,10]]},"632":{"position":[[17,10]]},"762":{"position":[[34,10]]}}}],["protocol",{"_index":88,"t":{"136":{"position":[[7,8]]},"247":{"position":[[26,9]]},"297":{"position":[[21,8]]},"349":{"position":[[20,8]]},"359":{"position":[[0,8]]},"394":{"position":[[0,9]]},"447":{"position":[[28,9]]},"718":{"position":[[4,8]]},"744":{"position":[[0,8]]},"882":{"position":[[6,9]]},"884":{"position":[[12,8]]},"886":{"position":[[15,8]]},"892":{"position":[[8,8]]},"894":{"position":[[15,8]]},"898":{"position":[[8,8]]},"900":{"position":[[15,8]]},"917":{"position":[[0,9]]},"1013":{"position":[[16,8]]},"1085":{"position":[[14,8]]},"1087":{"position":[[8,9]]},"1089":{"position":[[24,8]]},"1107":{"position":[[10,8]]}}}],["prove",{"_index":505,"t":{"811":{"position":[[0,7]]}}}],["provid",{"_index":610,"t":{"1132":{"position":[[12,8]]}}}],["pseudo",{"_index":433,"t":{"642":{"position":[[9,6]]}}}],["public",{"_index":379,"t":{"548":{"position":[[3,6]]},"586":{"position":[[5,6]]},"1105":{"position":[[21,6]]}}}],["publish",{"_index":478,"t":{"770":{"position":[[0,10]]}}}],["pull",{"_index":246,"t":{"395":{"position":[[5,4]]}}}],["push",{"_index":245,"t":{"395":{"position":[[0,4]]}}}],["qa",{"_index":9,"t":{"15":{"position":[[18,4]]},"1424":{"position":[[18,4]]}}}],["qualifi",{"_index":317,"t":{"494":{"position":[[38,7]]}}}],["qualiti",{"_index":7,"t":{"15":{"position":[[0,7]]},"1424":{"position":[[0,7]]}}}],["question",{"_index":158,"t":{"241":{"position":[[30,8]]}}}],["random",{"_index":591,"t":{"1075":{"position":[[0,6]]},"1077":{"position":[[0,6]]}}}],["rate",{"_index":168,"t":{"266":{"position":[[0,4]]},"504":{"position":[[44,4]]},"651":{"position":[[29,4]]},"762":{"position":[[53,4]]},"782":{"position":[[24,4]]}}}],["rational",{"_index":260,"t":{"427":{"position":[[0,9]]}}}],["reach",{"_index":220,"t":{"355":{"position":[[0,8]]}}}],["recap",{"_index":581,"t":{"1047":{"position":[[0,5]]}}}],["receiv",{"_index":52,"t":{"83":{"position":[[11,8]]}}}],["recurs",{"_index":405,"t":{"598":{"position":[[3,9]]}}}],["redund",{"_index":238,"t":{"378":{"position":[[15,9]]}}}],["refer",{"_index":72,"t":{"103":{"position":[[0,10]]},"166":{"position":[[0,10]]},"192":{"position":[[0,10]]},"211":{"position":[[0,10]]},"253":{"position":[[0,10]]},"321":{"position":[[0,10]]},"331":{"position":[[0,10]]},"365":{"position":[[0,10]]},"386":{"position":[[0,10]]},"407":{"position":[[0,10]]},"455":{"position":[[0,10]]},"528":{"position":[[0,10]]},"604":{"position":[[0,10]]},"712":{"position":[[0,10]]},"738":{"position":[[0,10]]},"788":{"position":[[0,10]]},"819":{"position":[[0,10]]},"836":{"position":[[0,10]]},"876":{"position":[[0,10]]},"904":{"position":[[0,10]]},"968":{"position":[[0,10]]},"1097":{"position":[[0,10]]},"1127":{"position":[[0,10]]},"1166":{"position":[[0,10]]},"1210":{"position":[[0,10]]},"1271":{"position":[[0,10]]},"1305":{"position":[[0,10]]},"1384":{"position":[[8,10]]}}}],["registr",{"_index":476,"t":{"766":{"position":[[10,12]]},"782":{"position":[[42,13]]}}}],["relat",{"_index":165,"t":{"259":{"position":[[0,7]]},"1087":{"position":[[18,7]]}}}],["relax",{"_index":574,"t":{"1037":{"position":[[3,5]]}}}],["relay",{"_index":94,"t":{"140":{"position":[[34,5]]},"148":{"position":[[4,5]]},"150":{"position":[[4,5]]},"634":{"position":[[65,5]]}}}],["reliabl",{"_index":296,"t":{"475":{"position":[[4,8]]}}}],["remot",{"_index":444,"t":{"653":{"position":[[21,6]]},"671":{"position":[[0,6]]}}}],["replac",{"_index":421,"t":{"619":{"position":[[20,11]]}}}],["replay",{"_index":638,"t":{"1196":{"position":[[0,6]]}}}],["report",{"_index":310,"t":{"492":{"position":[[13,7]]}}}],["requir",{"_index":299,"t":{"479":{"position":[[8,12]]},"688":{"position":[[16,12]]},"732":{"position":[[17,12]]},"1037":{"position":[[27,11]]}}}],["research",{"_index":109,"t":{"156":{"position":[[6,8]]},"923":{"position":[[0,8]]}}}],["resist",{"_index":634,"t":{"1182":{"position":[[11,10]]},"1342":{"position":[[15,10]]}}}],["resourc",{"_index":710,"t":{"1358":{"position":[[3,15]]},"1377":{"position":[[0,9]]}}}],["respect",{"_index":690,"t":{"1324":{"position":[[32,7]]}}}],["respons",{"_index":128,"t":{"200":{"position":[[10,8]]}}}],["result",{"_index":79,"t":{"116":{"position":[[10,7]]},"229":{"position":[[0,7]]},"403":{"position":[[0,7]]},"463":{"position":[[27,7]]},"1285":{"position":[[0,7]]}}}],["revers",{"_index":156,"t":{"241":{"position":[[0,9]]}}}],["review",{"_index":411,"t":{"600":{"position":[[46,7]]}}}],["rfc",{"_index":10,"t":{"21":{"position":[[0,3]]},"1432":{"position":[[0,3]]}}}],["rid",{"_index":358,"t":{"522":{"position":[[26,3]]}}}],["right",{"_index":697,"t":{"1328":{"position":[[20,6]]},"1394":{"position":[[25,6]]}}}],["risc",{"_index":269,"t":{"435":{"position":[[35,4]]}}}],["risc0",{"_index":646,"t":{"1225":{"position":[[3,7]]},"1288":{"position":[[3,5]]}}}],["rln",{"_index":93,"t":{"140":{"position":[[30,3]]},"142":{"position":[[0,3]]},"144":{"position":[[0,3]]},"146":{"position":[[0,3]]},"148":{"position":[[0,3]]},"150":{"position":[[0,3]]},"243":{"position":[[0,3]]},"351":{"position":[[25,3]]},"500":{"position":[[0,3]]},"502":{"position":[[10,3]]},"718":{"position":[[0,3]]},"732":{"position":[[37,3]]},"734":{"position":[[0,3]]},"874":{"position":[[23,3]]},"1371":{"position":[[4,3]]},"1373":{"position":[[8,3]]},"1375":{"position":[[4,3]]}}}],["roadmap",{"_index":283,"t":{"449":{"position":[[10,7]]},"995":{"position":[[44,7]]}}}],["role",{"_index":450,"t":{"675":{"position":[[0,5]]}}}],["rough",{"_index":446,"t":{"655":{"position":[[8,5]]},"746":{"position":[[13,5]]}}}],["rout",{"_index":479,"t":{"772":{"position":[[0,7]]},"1023":{"position":[[17,7]]},"1148":{"position":[[0,7]]}}}],["run",{"_index":467,"t":{"732":{"position":[[33,3]]},"1031":{"position":[[30,3]]}}}],["rust",{"_index":361,"t":{"524":{"position":[[43,4]]}}}],["rust'",{"_index":75,"t":{"114":{"position":[[18,6]]}}}],["sc",{"_index":23,"t":{"49":{"position":[[16,4]]},"1426":{"position":[[16,4]]}}}],["scalabl",{"_index":161,"t":{"247":{"position":[[0,11]]},"286":{"position":[[20,11]]},"317":{"position":[[7,11]]}}}],["scale",{"_index":423,"t":{"628":{"position":[[28,8]]}}}],["scheme",{"_index":503,"t":{"805":{"position":[[44,6]]}}}],["schnorr",{"_index":519,"t":{"884":{"position":[[4,7]]},"892":{"position":[[0,7]]},"898":{"position":[[0,7]]}}}],["scope",{"_index":172,"t":{"268":{"position":[[11,5]]},"1043":{"position":[[7,5]]},"1192":{"position":[[0,5]]}}}],["seamless",{"_index":278,"t":{"445":{"position":[[8,8]]}}}],["secret",{"_index":98,"t":{"146":{"position":[[15,6]]},"720":{"position":[[15,6]]}}}],["secur",{"_index":224,"t":{"357":{"position":[[22,8]]},"520":{"position":[[18,8]]},"728":{"position":[[0,8]]},"1156":{"position":[[0,6]]},"1172":{"position":[[22,9]]},"1174":{"position":[[0,8]]},"1324":{"position":[[3,8]]},"1344":{"position":[[5,8]]},"1434":{"position":[[0,8]]}}}],["self",{"_index":616,"t":{"1146":{"position":[[10,4]]}}}],["semaphor",{"_index":441,"t":{"651":{"position":[[19,9]]}}}],["send",{"_index":63,"t":{"91":{"position":[[4,7]]}}}],["separ",{"_index":258,"t":{"425":{"position":[[23,10]]},"496":{"position":[[32,10]]},"536":{"position":[[20,10]]},"1079":{"position":[[17,8]]}}}],["sequenc",{"_index":386,"t":{"564":{"position":[[0,9]]}}}],["servic",{"_index":106,"t":{"152":{"position":[[21,7]]},"243":{"position":[[8,7]]}}}],["session",{"_index":608,"t":{"1121":{"position":[[0,7]]}}}],["set",{"_index":494,"t":{"797":{"position":[[23,3]]}}}],["settl",{"_index":627,"t":{"1154":{"position":[[33,6]]}}}],["settlement",{"_index":104,"t":{"152":{"position":[[8,10]]},"1041":{"position":[[3,10]]}}}],["setup",{"_index":475,"t":{"766":{"position":[[0,5]]}}}],["shamir",{"_index":522,"t":{"890":{"position":[[9,6]]},"892":{"position":[[38,6]]},"894":{"position":[[45,6]]},"896":{"position":[[25,6]]},"898":{"position":[[36,6]]},"900":{"position":[[38,6]]}}}],["shamir'",{"_index":97,"t":{"146":{"position":[[6,8]]}}}],["shard",{"_index":570,"t":{"1027":{"position":[[9,8]]}}}],["share",{"_index":99,"t":{"146":{"position":[[22,7]]}}}],["sigma",{"_index":518,"t":{"882":{"position":[[0,5]]}}}],["signal",{"_index":502,"t":{"805":{"position":[[24,9]]}}}],["simpl",{"_index":594,"t":{"1079":{"position":[[0,6]]}}}],["simplifi",{"_index":563,"t":{"1013":{"position":[[3,8]]}}}],["simul",{"_index":304,"t":{"483":{"position":[[6,10]]},"844":{"position":[[0,10]]}}}],["size",{"_index":538,"t":{"949":{"position":[[8,4]]}}}],["slash",{"_index":481,"t":{"774":{"position":[[19,8]]}}}],["slide",{"_index":515,"t":{"864":{"position":[[0,7]]}}}],["smart",{"_index":21,"t":{"49":{"position":[[0,5]]},"558":{"position":[[3,5]]},"1426":{"position":[[0,5]]}}}],["smarter",{"_index":287,"t":{"461":{"position":[[29,7]]}}}],["smoother",{"_index":288,"t":{"461":{"position":[[49,8]]}}}],["snarko",{"_index":662,"t":{"1249":{"position":[[4,9]]}}}],["social",{"_index":177,"t":{"276":{"position":[[0,6]]}}}],["solut",{"_index":264,"t":{"431":{"position":[[15,9]]},"696":{"position":[[9,8]]},"754":{"position":[[9,9]]},"1005":{"position":[[0,8]]},"1079":{"position":[[7,9]]}}}],["sovereign",{"_index":617,"t":{"1146":{"position":[[15,9]]}}}],["sp1",{"_index":644,"t":{"1221":{"position":[[3,5]]},"1286":{"position":[[3,3]]}}}],["spam",{"_index":92,"t":{"140":{"position":[[21,4]]},"351":{"position":[[3,4]]},"609":{"position":[[32,4]]},"752":{"position":[[19,9]]},"762":{"position":[[29,4]]},"774":{"position":[[0,4]]}}}],["spars",{"_index":121,"t":{"186":{"position":[[0,6]]}}}],["spec",{"_index":582,"t":{"1051":{"position":[[0,5]]}}}],["specif",{"_index":637,"t":{"1194":{"position":[[20,8]]},"1283":{"position":[[8,14]]}}}],["spend",{"_index":397,"t":{"582":{"position":[[3,8]]}}}],["spn",{"_index":354,"t":{"520":{"position":[[53,4]]}}}],["spotlight",{"_index":125,"t":{"198":{"position":[[0,9]]}}}],["squar",{"_index":350,"t":{"520":{"position":[[0,6]]}}}],["stabil",{"_index":210,"t":{"339":{"position":[[19,9]]},"461":{"position":[[18,10]]}}}],["stack",{"_index":470,"t":{"744":{"position":[[9,5]]},"1144":{"position":[[30,5]]}}}],["stage",{"_index":682,"t":{"1299":{"position":[[0,5]]},"1301":{"position":[[0,5]]}}}],["state",{"_index":257,"t":{"425":{"position":[[17,5]]},"453":{"position":[[8,5]]},"496":{"position":[[26,5]]},"536":{"position":[[14,5]]},"548":{"position":[[10,5]]},"550":{"position":[[11,5]]},"840":{"position":[[8,5]]},"1049":{"position":[[8,5]]},"1111":{"position":[[10,5]]}}}],["statement",{"_index":715,"t":{"1392":{"position":[[19,10]]}}}],["static",{"_index":588,"t":{"1067":{"position":[[0,6]]},"1105":{"position":[[14,6]]}}}],["statu",{"_index":153,"t":{"237":{"position":[[19,6]]},"929":{"position":[[0,6]]}}}],["stellar",{"_index":670,"t":{"1257":{"position":[[4,9]]}}}],["step",{"_index":491,"t":{"784":{"position":[[22,5]]},"848":{"position":[[5,5]]},"1125":{"position":[[7,5]]}}}],["steward",{"_index":34,"t":{"73":{"position":[[3,7]]},"77":{"position":[[38,7]]},"83":{"position":[[3,7]]}}}],["storag",{"_index":464,"t":{"730":{"position":[[0,7]]},"778":{"position":[[0,7]]},"1150":{"position":[[0,7]]}}}],["store",{"_index":227,"t":{"361":{"position":[[9,5]]}}}],["strateg",{"_index":282,"t":{"449":{"position":[[0,9]]}}}],["strategi",{"_index":274,"t":{"439":{"position":[[0,10]]}}}],["strengthen",{"_index":332,"t":{"504":{"position":[[0,13]]}}}],["strong",{"_index":524,"t":{"892":{"position":[[26,6]]},"894":{"position":[[33,6]]}}}],["structur",{"_index":114,"t":{"174":{"position":[[5,9]]}}}],["studi",{"_index":419,"t":{"617":{"position":[[12,6]]},"651":{"position":[[12,6]]}}}],["substitut",{"_index":348,"t":{"518":{"position":[[8,12]]}}}],["subtre",{"_index":331,"t":{"502":{"position":[[43,8]]}}}],["summari",{"_index":110,"t":{"158":{"position":[[0,7]]},"319":{"position":[[0,7]]},"384":{"position":[[0,7]]},"451":{"position":[[0,7]]},"572":{"position":[[0,7]]},"1208":{"position":[[0,7]]},"1267":{"position":[[0,7]]},"1298":{"position":[[0,7]]},"1303":{"position":[[0,7]]}}}],["support",{"_index":509,"t":{"842":{"position":[[25,8]]},"1113":{"position":[[0,9]]},"1121":{"position":[[36,7]]}}}],["surveil",{"_index":434,"t":{"642":{"position":[[30,12]]},"1198":{"position":[[14,12]]}}}],["switzerland",{"_index":695,"t":{"1326":{"position":[[49,11]]}}}],["sync",{"_index":297,"t":{"475":{"position":[[13,4]]},"653":{"position":[[9,4]]},"657":{"position":[[9,4]]},"690":{"position":[[11,4]]},"700":{"position":[[0,7]]}}}],["synchron",{"_index":408,"t":{"600":{"position":[[13,15]]}}}],["system",{"_index":17,"t":{"39":{"position":[[12,7]]},"429":{"position":[[20,8]]},"437":{"position":[[23,7]]},"756":{"position":[[22,7]]},"758":{"position":[[4,7]]},"1422":{"position":[[12,7]]}}}],["tabl",{"_index":146,"t":{"225":{"position":[[6,6]]},"413":{"position":[[17,6]]},"1298":{"position":[[8,5]]}}}],["take",{"_index":689,"t":{"1324":{"position":[[24,4]]}}}],["takeaway",{"_index":183,"t":{"294":{"position":[[0,9]]}}}],["talk",{"_index":416,"t":{"611":{"position":[[0,6]]},"646":{"position":[[0,5]]},"1384":{"position":[[0,5]]}}}],["tech",{"_index":435,"t":{"642":{"position":[[43,4]]}}}],["technic",{"_index":174,"t":{"270":{"position":[[0,9]]},"274":{"position":[[0,9]]},"760":{"position":[[0,9]]}}}],["tell",{"_index":577,"t":{"1039":{"position":[[39,4]]}}}],["term",{"_index":469,"t":{"742":{"position":[[6,5]]},"760":{"position":[[10,5]]},"1408":{"position":[[24,5]]}}}],["terminolog",{"_index":167,"t":{"262":{"position":[[6,11]]}}}],["test",{"_index":18,"t":{"39":{"position":[[20,7]]},"492":{"position":[[5,7]]},"692":{"position":[[0,4]]},"1281":{"position":[[0,7]]},"1422":{"position":[[20,7]]}}}],["testnet",{"_index":102,"t":{"150":{"position":[[23,7]]},"921":{"position":[[0,7]]},"1055":{"position":[[8,7]]}}}],["theoret",{"_index":179,"t":{"286":{"position":[[8,11]]},"945":{"position":[[0,11]]}}}],["theori",{"_index":492,"t":{"796":{"position":[[0,6]]}}}],["thing",{"_index":586,"t":{"1061":{"position":[[0,6]]}}}],["third",{"_index":686,"t":{"1322":{"position":[[3,5]]},"1330":{"position":[[3,5]]},"1396":{"position":[[3,5]]}}}],["thought",{"_index":149,"t":{"231":{"position":[[8,8]]},"278":{"position":[[8,8]]}}}],["threat",{"_index":635,"t":{"1190":{"position":[[13,6]]}}}],["through",{"_index":442,"t":{"651":{"position":[[43,7]]},"762":{"position":[[45,7]]}}}],["time",{"_index":234,"t":{"374":{"position":[[23,4]]},"392":{"position":[[17,4]]},"690":{"position":[[16,4]]}}}],["tke",{"_index":6,"t":{"9":{"position":[[16,5]]},"1420":{"position":[[16,5]]}}}],["token",{"_index":4,"t":{"9":{"position":[[0,5]]},"1420":{"position":[[0,5]]}}}],["topic",{"_index":37,"t":{"73":{"position":[[29,5]]},"79":{"position":[[26,5]]},"225":{"position":[[0,5]]},"927":{"position":[[9,6]]},"1017":{"position":[[3,5]]},"1027":{"position":[[3,5]]},"1081":{"position":[[7,5]]}}}],["toward",{"_index":325,"t":{"500":{"position":[[8,7]]}}}],["toy",{"_index":612,"t":{"1134":{"position":[[21,3]]}}}],["track",{"_index":560,"t":{"1009":{"position":[[0,5]]},"1023":{"position":[[0,5]]},"1031":{"position":[[0,5]]}}}],["traffic",{"_index":545,"t":{"962":{"position":[[8,7]]}}}],["trail",{"_index":131,"t":{"203":{"position":[[11,8]]}}}],["transact",{"_index":626,"t":{"1154":{"position":[[10,9]]}}}],["transfer",{"_index":233,"t":{"374":{"position":[[14,8]]},"392":{"position":[[8,8]]}}}],["transit",{"_index":248,"t":{"395":{"position":[[16,10]]}}}],["transmiss",{"_index":239,"t":{"378":{"position":[[25,13]]}}}],["transpar",{"_index":703,"t":{"1348":{"position":[[3,12]]}}}],["transport",{"_index":235,"t":{"376":{"position":[[14,9]]}}}],["travers",{"_index":598,"t":{"1093":{"position":[[4,9]]}}}],["tree",{"_index":113,"t":{"174":{"position":[[0,4]]},"176":{"position":[[7,5]]},"180":{"position":[[7,4]]},"184":{"position":[[21,5]]},"186":{"position":[[14,5]]},"190":{"position":[[7,5]]},"596":{"position":[[3,5]]},"690":{"position":[[27,4]]},"768":{"position":[[34,4]]},"797":{"position":[[52,4]]}}}],["trilemma",{"_index":632,"t":{"1180":{"position":[[10,8]]}}}],["triton",{"_index":658,"t":{"1245":{"position":[[4,8]]}}}],["truli",{"_index":316,"t":{"494":{"position":[[32,5]]}}}],["truth",{"_index":578,"t":{"1039":{"position":[[48,5]]}}}],["two",{"_index":263,"t":{"429":{"position":[[16,3]]}}}],["type",{"_index":382,"t":{"554":{"position":[[13,5]]},"1184":{"position":[[9,5]]}}}],["typic",{"_index":127,"t":{"200":{"position":[[2,7]]}}}],["under",{"_index":410,"t":{"600":{"position":[[39,6]]}}}],["union",{"_index":694,"t":{"1326":{"position":[[39,5]]}}}],["unstructur",{"_index":338,"t":{"506":{"position":[[81,12]]}}}],["up",{"_index":554,"t":{"995":{"position":[[12,2]]},"1059":{"position":[[7,2]]},"1367":{"position":[[6,3]]}}}],["upcom",{"_index":550,"t":{"985":{"position":[[13,8]]},"1063":{"position":[[0,8]]}}}],["updat",{"_index":417,"t":{"613":{"position":[[8,6]]},"623":{"position":[[5,6]]}}}],["us",{"_index":219,"t":{"351":{"position":[[19,5]]},"536":{"position":[[51,4]]},"538":{"position":[[0,3]]},"578":{"position":[[0,3],[17,3]]},"896":{"position":[[9,3]]},"925":{"position":[[0,3]]},"1320":{"position":[[69,3]]},"1382":{"position":[[15,3]]},"1408":{"position":[[33,3]]}}}],["usag",{"_index":142,"t":{"221":{"position":[[13,5]]},"734":{"position":[[4,5]]}}}],["user",{"_index":46,"t":{"79":{"position":[[3,4]]},"81":{"position":[[3,4]]},"268":{"position":[[30,6]]},"496":{"position":[[13,4]]},"532":{"position":[[20,4]]},"556":{"position":[[13,5]]},"562":{"position":[[0,4]]},"720":{"position":[[10,4]]},"724":{"position":[[20,4]]},"842":{"position":[[9,5]]},"1031":{"position":[[25,4]]},"1132":{"position":[[32,4]]}}}],["user'",{"_index":53,"t":{"83":{"position":[[24,6]]}}}],["utxo",{"_index":388,"t":{"566":{"position":[[27,4]]},"568":{"position":[[29,4]]},"570":{"position":[[3,4]]},"572":{"position":[[11,4]]},"578":{"position":[[53,4]]}}}],["v",{"_index":270,"t":{"435":{"position":[[40,2]]},"590":{"position":[[0,2]]},"1348":{"position":[[0,2]]}}}],["v1",{"_index":436,"t":{"644":{"position":[[5,2]]},"974":{"position":[[50,2]]},"977":{"position":[[19,2]]},"979":{"position":[[8,2]]},"1021":{"position":[[8,2]]}}}],["v1.4",{"_index":250,"t":{"397":{"position":[[10,4]]}}}],["v2",{"_index":414,"t":{"607":{"position":[[25,2]]},"609":{"position":[[56,2]]},"611":{"position":[[17,2]]},"613":{"position":[[5,2]]},"615":{"position":[[25,3]]},"638":{"position":[[5,2]]},"644":{"position":[[16,3]]},"646":{"position":[[27,2]]},"661":{"position":[[5,2]]},"663":{"position":[[5,2]]},"912":{"position":[[5,2]]},"927":{"position":[[24,2]]},"933":{"position":[[14,2]]},"945":{"position":[[33,2]]},"974":{"position":[[61,2]]},"979":{"position":[[14,2]]},"981":{"position":[[9,2]]},"983":{"position":[[8,2]]},"985":{"position":[[8,2]]}}}],["v2.0",{"_index":251,"t":{"399":{"position":[[10,4]]}}}],["v3",{"_index":324,"t":{"500":{"position":[[4,3]]}}}],["v5",{"_index":218,"t":{"349":{"position":[[29,2]]},"1071":{"position":[[10,2]]}}}],["vac",{"_index":319,"t":{"498":{"position":[[0,3]]},"611":{"position":[[7,4]]},"646":{"position":[[17,4]]},"655":{"position":[[0,3]]},"974":{"position":[[9,3]]},"975":{"position":[[3,3]]}}}],["vagu",{"_index":135,"t":{"207":{"position":[[21,5]]}}}],["valid",{"_index":499,"t":{"803":{"position":[[32,10]]}}}],["valida",{"_index":649,"t":{"1231":{"position":[[3,8]]},"1296":{"position":[[3,6]]}}}],["verif",{"_index":275,"t":{"441":{"position":[[28,12]]},"813":{"position":[[0,12]]}}}],["verifi",{"_index":329,"t":{"502":{"position":[[0,9]]}}}],["verkl",{"_index":123,"t":{"190":{"position":[[0,6]]}}}],["version",{"_index":303,"t":{"481":{"position":[[25,7]]}}}],["vi",{"_index":403,"t":{"592":{"position":[[0,3]]},"1350":{"position":[[0,3]]}}}],["via",{"_index":489,"t":{"782":{"position":[[29,3]]}}}],["viabl",{"_index":302,"t":{"481":{"position":[[18,6]]}}}],["view",{"_index":401,"t":{"588":{"position":[[4,7]]}}}],["vii",{"_index":404,"t":{"594":{"position":[[0,4]]},"1352":{"position":[[0,4]]}}}],["viii",{"_index":705,"t":{"1354":{"position":[[0,5]]}}}],["virtual",{"_index":265,"t":{"433":{"position":[[8,7]]},"492":{"position":[[47,7]]},"494":{"position":[[64,7]]},"552":{"position":[[24,7]]}}}],["vote",{"_index":56,"t":{"85":{"position":[[15,6]]},"87":{"position":[[3,6]]}}}],["vs",{"_index":437,"t":{"644":{"position":[[8,2]]},"872":{"position":[[14,2]]}}}],["waku",{"_index":29,"t":{"65":{"position":[[0,4]]},"69":{"position":[[0,4]]},"132":{"position":[[0,4]]},"134":{"position":[[0,4]]},"136":{"position":[[0,4]]},"138":{"position":[[0,4]]},"239":{"position":[[16,4]]},"245":{"position":[[0,4]]},"251":{"position":[[13,4]]},"296":{"position":[[12,4]]},"299":{"position":[[11,4]]},"337":{"position":[[7,4]]},"349":{"position":[[0,4]]},"504":{"position":[[72,4]]},"510":{"position":[[21,4],[33,4]]},"607":{"position":[[14,5],[20,4]]},"609":{"position":[[51,4]]},"611":{"position":[[12,4]]},"613":{"position":[[0,4]]},"615":{"position":[[20,4]]},"623":{"position":[[0,4]]},"628":{"position":[[14,4]]},"630":{"position":[[0,4]]},"634":{"position":[[0,4],[60,4]]},"636":{"position":[[47,4]]},"638":{"position":[[0,4]]},"644":{"position":[[0,4],[11,4]]},"646":{"position":[[22,4]]},"649":{"position":[[20,4]]},"661":{"position":[[0,4]]},"663":{"position":[[0,4]]},"803":{"position":[[43,6]]},"805":{"position":[[51,6]]},"826":{"position":[[0,4]]},"842":{"position":[[20,4]]},"846":{"position":[[19,4]]},"912":{"position":[[0,4]]},"927":{"position":[[19,4]]},"945":{"position":[[28,4]]},"974":{"position":[[45,4],[56,4]]},"977":{"position":[[14,4]]},"979":{"position":[[3,4]]},"981":{"position":[[4,4]]},"983":{"position":[[3,4]]},"985":{"position":[[3,4]]},"1021":{"position":[[3,4]]},"1057":{"position":[[0,4]]},"1113":{"position":[[30,4]]}}}],["waku'",{"_index":462,"t":{"722":{"position":[[0,6]]}}}],["walk",{"_index":592,"t":{"1075":{"position":[[7,4]]},"1077":{"position":[[7,4]]}}}],["walletconnect",{"_index":534,"t":{"933":{"position":[[0,13]]}}}],["want",{"_index":613,"t":{"1136":{"position":[[11,5]]}}}],["wasm",{"_index":268,"t":{"435":{"position":[[26,4]]}}}],["way",{"_index":485,"t":{"780":{"position":[[15,3]]}}}],["weak",{"_index":526,"t":{"898":{"position":[[26,4]]}}}],["web",{"_index":584,"t":{"1057":{"position":[[5,3]]}}}],["web3",{"_index":85,"t":{"128":{"position":[[0,4]]},"1144":{"position":[[25,4]]}}}],["websit",{"_index":685,"t":{"1320":{"position":[[80,7]]},"1324":{"position":[[47,7]]},"1396":{"position":[[15,7]]},"1408":{"position":[[16,7]]}}}],["wechat",{"_index":420,"t":{"619":{"position":[[13,6]]},"1132":{"position":[[5,6]]},"1134":{"position":[[4,6]]}}}],["welcom",{"_index":36,"t":{"73":{"position":[[21,7]]},"79":{"position":[[18,7]]},"93":{"position":[[13,7]]}}}],["what'",{"_index":418,"t":{"615":{"position":[[0,6]]},"667":{"position":[[0,6]]},"993":{"position":[[3,6]]},"1162":{"position":[[0,6]]}}}],["whisper",{"_index":178,"t":{"286":{"position":[[0,7]]},"649":{"position":[[7,7]]},"846":{"position":[[28,7]]},"974":{"position":[[34,7]]},"977":{"position":[[3,7]]}}}],["window",{"_index":516,"t":{"864":{"position":[[8,6]]}}}],["work",{"_index":71,"t":{"101":{"position":[[7,4]]},"353":{"position":[[7,4]]},"489":{"position":[[7,4]]},"682":{"position":[[7,4]]},"708":{"position":[[7,4]]},"736":{"position":[[7,4]]},"817":{"position":[[7,4]]},"966":{"position":[[7,4]]},"1134":{"position":[[11,5]]},"1208":{"position":[[19,4]]},"1375":{"position":[[8,5]]}}}],["write",{"_index":712,"t":{"1367":{"position":[[0,5]]}}}],["x",{"_index":709,"t":{"1358":{"position":[[0,2]]}}}],["xk1",{"_index":605,"t":{"1117":{"position":[[4,3]]}}}],["xx",{"_index":606,"t":{"1119":{"position":[[4,2]]}}}],["xxpsk0",{"_index":607,"t":{"1119":{"position":[[11,6]]}}}],["zero",{"_index":312,"t":{"492":{"position":[[32,4]]},"494":{"position":[[49,4]]},"552":{"position":[[8,5]]}}}],["zerokit",{"_index":108,"t":{"154":{"position":[[0,7]]}}}],["zk",{"_index":13,"t":{"27":{"position":[[25,2]]},"130":{"position":[[0,2]]},"598":{"position":[[41,2]]},"1430":{"position":[[23,2]]}}}],["zkllvm",{"_index":674,"t":{"1261":{"position":[[4,8]]}}}],["zkmip",{"_index":648,"t":{"1229":{"position":[[3,8]]},"1292":{"position":[[3,6]]}}}],["zkmove",{"_index":676,"t":{"1263":{"position":[[4,8]]}}}],["zko",{"_index":656,"t":{"1243":{"position":[[4,6]]}}}],["zkp",{"_index":272,"t":{"437":{"position":[[9,3]]}}}],["zksnark",{"_index":443,"t":{"651":{"position":[[51,8]]}}}],["zkvm",{"_index":309,"t":{"492":{"position":[[0,4]]},"494":{"position":[[10,6]]},"508":{"position":[[14,4]]},"552":{"position":[[3,4]]},"598":{"position":[[44,4]]},"1214":{"position":[[10,5]]},"1216":{"position":[[4,5]]},"1220":{"position":[[0,4]]}}}],["zkwasm",{"_index":651,"t":{"1235":{"position":[[3,8]]},"1294":{"position":[[3,6]]}}}]],"pipeline":["stemmer"]}},{"documents":[{"i":1,"t":"In this post, we recap Vac's achievements in 2024 and look forward to 2025.","s":"Vac 2024 Year in Review","u":"/rlog/2024-recap","p":1},{"i":57,"t":"Archive","s":"","u":"/rlog/archive","p":57},{"i":58,"t":"This post introduces de-MLS, a decentralized variant of Message Layer Security (MLS)","s":"Decentralized Message Layer Security (De-MLS) with Waku","u":"/rlog/de-mls-with-waku","p":58},{"i":105,"t":"Vac - Communication, Privacy, Etc.","s":"","u":"/rlog/authors","p":105},{"i":106,"t":"Zerokit is a toolkit","s":"Zerokit optimizations: A performance journey","u":"/rlog/2025-zerokit-perf","p":106},{"i":120,"t":"What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it.","s":"Building Privacy-Protecting Infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","p":120},{"i":160,"t":"Device pairing and secure message exchange using Waku and noise protocol.","s":"Device Pairing in Js-waku and Go-waku","u":"/rlog/device-pairing-in-js-waku-and-go-waku","p":160},{"i":168,"t":"A look at EIP-1459 and the benefits of DNS based discovery.","s":"DNS Based Discovery","u":"/rlog/dns-based-discovery","p":168},{"i":170,"t":"In this post, we introduce a crucial data structure used throughout web3.","s":"Vac 101: Climbing Merkle Trees","u":"/rlog/climbing-merkle-trees","p":170},{"i":194,"t":"A look at typical ethical shortfalls in the global surveillance tech industry.","s":"Opinion: Pseudo-ethics in the Surveillance Tech Industry","u":"/rlog/ethics-surveillance-tech","p":194},{"i":213,"t":"Looking at discv5 and the theoretical numbers behind finding peers.","s":"Feasibility Study: Discv5","u":"/rlog/feasibility-discv5","p":213},{"i":235,"t":"Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.","s":"The Future of Waku Network: Scaling, Incentivization, and Heterogeneity","u":"/rlog/future-of-waku-network","p":235},{"i":255,"t":"A research log. Zero knowledge signaling as a rate limiting mechanism to prevent spam in p2p networks.","s":"Feasibility Study: Semaphore rate limiting through zkSNARKs","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","p":255},{"i":282,"t":"A research log. Why Whisper doesn't scale and how to fix it.","s":"Fixing Whisper with Waku","u":"/rlog/fixing-whisper-with-waku","p":282},{"i":303,"t":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","s":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","u":"/rlog/GossipSub Improvements","p":303},{"i":323,"t":"This post provides quick insights into the IDONTWANT message performance and highlights minor tweaks that can further contribute to performance gains.","s":"Libp2p GossipSub IDONTWANT Message Performance Impact","u":"/rlog/gsub-idontwant-perf-eval","p":323},{"i":333,"t":"Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.","s":"Introducing nwaku","u":"/rlog/introducing-nwaku","p":333},{"i":367,"t":"Large Message Handling in GossipSub: Potential Improvements","s":"Large Message Handling in GossipSub: Potential Improvements","u":"/rlog/gsub-largemsg-improvements","p":367},{"i":388,"t":"The original GossipSub design emphasizes robustness, with less focus on message sizes.","s":"Scaling libp2p GossipSub for Large Messages: An Evaluation of Performance Improvement Proposals","u":"/rlog/gsub-perf-imp-comparison","p":388},{"i":409,"t":"A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ.","s":"From Kademlia to Discv5","u":"/rlog/kademlia-to-discv5","p":409},{"i":421,"t":"Nescience, a privacy-first blockchain zkVM.","s":"Nescience - A zkVM leveraging hiding properties","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","p":421},{"i":459,"t":"Welcome to the first edition of Nim in Logos — a newsletter covering major Nim features from Logos' perspective.","s":"Nim in Logos - 1st Edition","u":"/rlog/nim-in-logos-01","p":459},{"i":469,"t":"A research log. Reliable and decentralized, pick two.","s":"P2P Data Sync for Mobile","u":"/rlog/p2p-data-sync-for-mobile","p":469},{"i":491,"t":"Blog","s":"","u":"/rlog/page/2","p":491},{"i":512,"t":"This article introduces MDSECheck method — a novel approach","s":"The MDSECheck method: choosing secure square MDS matrices for P-SP-networks","u":"/rlog/mdsecheck-method","p":512},{"i":530,"t":"Nescience: A user-centric state-separation architecture.","s":"Nescience: A User-Centric State-Separation Architecture","u":"/rlog/Nescience-state-separation-architecture","p":530},{"i":606,"t":"Blog","s":"","u":"/rlog/page/4","p":606},{"i":627,"t":"Blog","s":"","u":"/rlog/page/3","p":627},{"i":648,"t":"Blog","s":"","u":"/rlog/page/5","p":648},{"i":659,"t":"JS-Waku is bringing Waku v2 to the browser. Learn what we achieved so far and what is next in our pipeline!","s":"Presenting JS-Waku: Waku v2 in the Browser","u":"/rlog/presenting-js-waku","p":659},{"i":669,"t":"A research log. Asynchronous P2P messaging? Remote logs to the rescue!","s":"P2P Data Sync with a Remote Log","u":"/rlog/remote-log","p":669},{"i":684,"t":"How resource-restricted devices can verify RLN proofs fast and efficiently.","s":"Verifying RLN Proofs in Light Clients with Subtrees","u":"/rlog/rln-light-verifiers","p":684},{"i":714,"t":"Rate Limiting Nullifiers in practice, applied to an anonymous p2p network, like Waku.","s":"Strengthening Anonymous DoS Prevention with Rate Limiting Nullifiers in Waku","u":"/rlog/rln-anonymous-dos-prevention","p":714},{"i":740,"t":"Vac is a modular peer-to-peer messaging stack, with a focus on secure messaging. Overview of terms, stack and open problems.","s":"Vac - A Rough Overview","u":"/rlog/vac-overview","p":740},{"i":748,"t":"This post is going to give you an overview of how spam protection can be achieved in Waku Relay through rate-limiting nullifiers. We will cover a summary of spam-protection methods in centralized and p2p systems, and the solution overview and details of the economic spam-protection method. The open issues and future steps are discussed in the end.","s":"Privacy-preserving p2p economic spam protection in Waku v2","u":"/rlog/rln-relay","p":748},{"i":792,"t":"Improving on the previous version of RLN by allowing dynamic epoch sizes.","s":"RLN-v3: Towards a Flexible and Cost-Efficient Implementation","u":"/rlog/rln-v3","p":792},{"i":821,"t":"Waku is an open communication protocol and network. Decentralized apps and infrastructure can use Waku for their","s":"Waku for All Decentralized Applications and Infrastructures","u":"/rlog/waku-for-all","p":821},{"i":838,"t":"A research log. What's the current state of Waku? How many users does it support? What are the bottlenecks? What's next?","s":"Waku Update","u":"/rlog/waku-update","p":838},{"i":852,"t":"We examine two data structures: Bloom filters and Cuckoo filters.","s":"Vac 101: Membership with Bloom Filters and Cuckoo Filters","u":"/rlog/vac101-membership-with-bloom-filters-and-cuckoo-filters","p":852},{"i":878,"t":"In this post, we introduce a common technique used to convert interactive protocols to their noninteractive variant.","s":"Vac 101: Transforming an Interactive Protocol to a Noninteractive Argument","u":"/rlog/vac101-fiat-shamir","p":878},{"i":906,"t":"Learn more about Waku v2, its origins, goals, protocols, implementation and ongoing research. Understand how it is used and how it can be useful for messaging in Ethereum.","s":"[Talk at COSCUP] Vac, Waku v2 and Ethereum Messaging","u":"/rlog/waku-v2-ethereum-coscup","p":906},{"i":941,"t":"A local comparison of bandwidth profiles showing significantly improved scalability in Waku v2 over Waku v1.","s":"Waku v1 vs Waku v2: Bandwidth Comparison","u":"/rlog/waku-v1-v2-bandwidth-comparison","p":941},{"i":970,"t":"Talk from Taipei Ethereum Meetup. Read on to find out about our journey from Whisper to Waku v2, as well as how Waku v2 can be useful for Etherum Messaging.","s":"[Talk] Vac, Waku v2 and Ethereum Messaging","u":"/rlog/waku-v2-ethereum-messaging","p":970},{"i":999,"t":"Read about our plans for Waku v2, moving to libp2p, better routing, adaptive nodes and accounting!","s":"What's the Plan for Waku v2?","u":"/rlog/waku-v2-plan","p":999},{"i":1045,"t":"A research log. Read on to find out what is going on with Waku v2, a messaging protocol. What has been happening? What is coming up next?","s":"Waku v2 Update","u":"/rlog/waku-v2-update","p":1045},{"i":1065,"t":"Introducing and discussing ambient peer discovery methods currently used by Waku v2, as well as future plans in this area.","s":"Waku v2 Ambient Peer Discovery","u":"/rlog/wakuv2-apd","p":1065},{"i":1099,"t":"We provide an overview of the Noise Protocol Framework as a tool to design efficient and secure key-exchange mechanisms in Waku2.","s":"Noise handshakes as key-exchange mechanism for Waku","u":"/rlog/wakuv2-noise","p":1099},{"i":1129,"t":"What would a self-sovereign, private, censorship-resistant and open alternative to WeChat look like?","s":"What Would a WeChat Replacement Need?","u":"/rlog/wechat-replacement-need","p":1129},{"i":1170,"t":"Introducing a basic threat model and privacy/anonymity analysis for the Waku v2 relay protocol.","s":"Waku Privacy and Anonymity Analysis Part I: Definitions and Waku Relay","u":"/rlog/wakuv2-relay-anon","p":1170},{"i":1212,"t":"{/ truncate /}","s":"Exploring zkVMs: Which Projects Truly Qualify as Zero-Knowledge Virtual Machines?","u":"/rlog/zkVM-explorations","p":1212},{"i":1273,"t":"Join the Vac Community!","s":"Join the community","u":"/community","p":1273},{"i":1275,"t":"{/ truncate /}","s":"zkVM Testing Report: Evaluating Zero-Knowledge Virtual Machines for Nescience","u":"/rlog/zkVM-testing","p":1275},{"i":1307,"t":"How to Contribute","s":"Contribute","u":"/contribute","p":1307},{"i":1312,"t":"Vac - Communication, Privacy, Etc.","s":"Current job openings","u":"/join-us","p":1312},{"i":1314,"t":"Waku v2 training session","s":"","u":"/media","p":1314},{"i":1316,"t":"Last updated: 9 February 2024","s":"Privacy Policy","u":"/privacy-policy","p":1316},{"i":1336,"t":"These principles have been inherited from https://our.status.im/our-principles/. Only minor stylistic changes have been made to them.","s":"","u":"/principles","p":1336},{"i":1360,"t":"Vac Research conducts innovative exploration within the IFT.","s":"Vac Research","u":"/research","p":1360},{"i":1362,"t":"The Vac RFC unit serves as a vital cornerstone in the Logos collective,","s":"Vac RFC Process","u":"/rfcprocess","p":1362},{"i":1364,"t":"Papers","s":"Publications","u":"/publications","p":1364},{"i":1369,"t":"A privacy-preserving rate limiting protocol for decentralized systems, powered by ZK.","s":"Rate Limiting Nullifier (RLN)","u":"/rln","p":1369},{"i":1386,"t":"Last updated: 14 February 2024","s":"Terms of Use","u":"/terms","p":1386},{"i":1410,"t":"We take security seriously at Vac and across the Institute of Free Technology and its affiliates.","s":"Security","u":"/security","p":1410},{"i":1412,"t":"Vac incubator projects are emerging initiatives that stem from Vac's research efforts.","s":"Vac Incubator Projects","u":"/vips","p":1412},{"i":1416,"t":"Vac's R&D Service Units are integral to supporting IFT projects by researching and developing base components","s":"Vac R&D Service Units","u":"/vsus","p":1416},{"i":1436,"t":"Vac is a principle-driven R&D team that provides comprehensive technical support to IFT startups.","s":"About Vac","u":"/","p":1436}],"index":{"version":"2.3.9","fields":["t"],"fieldVectors":[["t/1",[0,2.439,1,3.972,2,3.087,3,3.087,4,3.087,5,2.159,6,3.972,7,3.972]],["t/57",[8,5.968]],["t/58",[0,2.227,9,2.09,10,3.626,11,5.058,12,2.578,13,3.139,14,1.682,15,3.139,16,2.386]],["t/105",[17,2.525,18,3.231,19,3.231,20,4.251]],["t/106",[21,4.82,22,5.568]],["t/120",[5,1.461,15,1.386,18,1.054,19,1.769,21,1.386,23,3.006,24,2.326,25,1.601,26,2.688,27,3.473,28,0.95,29,1.386,30,1.601,31,1.461,32,2.688,33,1.386,34,0.923,35,1.601,36,1.601,37,1.601,38,1.386,39,1.601,40,1.138,41,1.601,42,1.601,43,1.386,44,1.386,45,1.601]],["t/160",[14,1.759,16,2.495,28,1.34,31,2.06,46,3.282,47,3.791,48,3.282,49,3.282,50,2.06]],["t/168",[5,2.267,51,4.172,52,4.172,53,4.172,54,4.172,55,3.241,56,3.241]],["t/170",[0,2.439,9,2.29,29,3.438,31,2.159,57,3.972,58,3.438,59,3.438,60,3.972]],["t/194",[5,2.159,61,3.972,62,3.972,63,3.972,64,3.972,65,3.972,66,3.972,67,3.972]],["t/213",[5,2.267,68,3.611,69,4.172,70,4.172,71,4.172,72,3.241,73,2.965]],["t/235",[5,1.812,28,1.179,33,2.887,34,1.922,74,2.591,75,3.335,76,2.887,77,2.887,78,3.335,79,3.335,80,2.591,81,2.371]],["t/255",[34,1.922,82,1.627,83,2.048,84,3.335,85,3.335,86,3.335,87,2.371,88,2.371,89,2.887,90,3.335,91,2.887,92,2.195]],["t/282",[77,3.802,82,2.143,83,2.697,93,3.802,94,4.392,95,4.392]],["t/303",[14,1.682,34,2.09,92,2.386,96,2.817,97,2.578,98,3.626,99,3.626,100,2.817,101,3.626,102,3.626]],["t/323",[0,1.896,14,1.432,103,2.399,104,2.672,105,3.088,106,3.088,107,4.509,108,3.088,109,2.672,110,3.088,111,3.088,112,2.672,113,3.088]],["t/333",[9,1.657,28,1.016,55,2.233,80,2.233,81,2.043,114,2.874,115,2.488,116,1.402,117,2.874,118,2.874,119,2.488,120,2.874,121,2.874,122,2.233,123,2.233,124,2.488]],["t/367",[14,2.037,96,3.413,97,3.122,125,4.392,126,4.392,127,4.392]],["t/388",[14,1.759,96,2.946,100,2.946,123,2.946,128,3.282,129,3.791,130,3.791,131,3.791,132,3.282]],["t/409",[5,1.743,34,1.848,38,2.775,56,2.491,68,2.775,73,3.295,104,2.775,133,3.207,134,3.207,135,3.207,136,2.775,137,3.207]],["t/421",[19,3.051,138,4.013,139,4.013,140,4.637,141,4.637]],["t/459",[115,4.012,139,2.775,142,3.207,143,3.207,144,4.012,145,2.279,146,3.207,147,2.775,148,3.207,149,3.207,150,3.207]],["t/469",[12,3.122,82,2.143,83,2.697,151,4.392,152,4.392,153,3.802]],["t/491",[154,4.242]],["t/512",[9,2.404,145,2.965,155,4.172,156,4.172,157,3.241,158,4.172,159,4.172]],["t/530",[138,3.802,160,3.802,161,4.392,162,3.802,163,4.392,164,4.392]],["t/606",[154,4.242]],["t/627",[154,4.242]],["t/648",[154,4.242]],["t/659",[3,2.7,28,1.734,74,2.7,116,1.695,165,3.475,166,3.475,167,3.475,168,3.475,169,2.7,170,3.475]],["t/669",[14,1.843,82,1.938,83,3.307,92,2.614,171,3.972,172,3.972,173,3.972]],["t/684",[46,3.438,174,3.972,175,3.972,176,3.972,177,3.438,178,3.972,179,3.972,180,3.438]],["t/714",[28,1.34,34,2.185,87,2.695,88,2.695,92,2.495,181,3.282,182,3.791,183,3.791,184,3.791]],["t/740",[14,2.092,16,2.032,17,1.587,73,3.205,123,2.399,185,3.088,186,4.509,187,2.399,188,3.088,189,2.195,190,3.088]],["t/748",[0,1.088,3,1.377,23,3.231,28,0.626,76,1.534,81,1.259,87,1.259,88,1.259,91,3.231,92,1.166,119,1.534,136,1.534,147,1.534,157,2.272,181,1.534,187,2.272,189,1.259,191,1.534,192,1.772,193,1.534,194,1.772,195,1.534,196,1.772,197,1.772,198,1.772,199,1.772,200,1.534,201,1.772]],["t/792",[97,2.824,132,3.438,177,3.438,202,3.972,203,3.972,204,3.972,205,3.972,206,3.972]],["t/821",[12,2.578,18,2.386,24,3.139,28,1.787,31,1.971,34,2.09,50,1.971,189,2.578,207,3.626]],["t/838",[28,1.179,82,1.627,83,2.048,122,2.591,160,2.887,162,2.887,169,2.591,208,4.768,209,3.335,210,2.591,211,3.335]],["t/852",[58,3.438,59,3.438,153,3.438,212,3.972,213,3.972,214,5.385,215,3.972]],["t/878",[0,2.227,9,2.09,13,3.139,31,1.971,50,1.971,216,3.626,217,3.626,218,3.626,219,3.626,220,3.626]],["t/906",[14,1.381,28,1.052,31,2.386,44,2.577,50,1.618,74,2.313,82,1.452,116,1.452,128,2.577,221,2.977,222,2.977,223,2.977,224,2.977,225,2.577]],["t/941",[28,1.638,97,2.279,116,1.564,226,3.207,227,3.207,228,3.207,229,3.207,230,3.207,231,3.207,232,3.207,233,3.207,234,3.207]],["t/970",[14,1.289,28,1.474,31,1.51,40,1.975,72,2.159,93,2.405,116,2.034,225,2.405,235,2.778,236,2.778,237,2.778,238,2.405,239,2.778,240,2.405,241,2.778]],["t/999",[28,1.228,40,2.47,43,3.007,116,1.695,242,3.007,243,3.475,244,3.475,245,3.475,246,3.475,247,3.475,248,3.475]],["t/1045",[14,1.432,28,1.091,40,2.195,50,1.678,72,2.399,82,1.506,83,1.896,116,1.506,169,2.399,191,2.672,238,2.672,249,3.088,250,3.088,251,3.088]],["t/1065",[9,1.78,28,1.091,31,1.678,56,2.399,73,2.195,81,2.195,116,1.506,122,2.399,124,2.672,157,2.399,200,2.672,240,2.672,242,2.672,252,3.088]],["t/1099",[16,2.11,48,2.775,49,2.775,50,1.743,89,2.775,100,2.491,103,2.491,180,2.775,187,2.491,253,3.207,254,3.207,255,3.207,256,3.207]],["t/1129",[5,2.06,189,2.695,257,3.791,258,3.791,259,3.791,260,3.791,261,3.791,262,3.791,263,3.791]],["t/1170",[9,2.09,28,1.281,50,1.971,116,1.769,193,3.139,264,3.626,265,3.626,266,3.626,267,3.626,268,3.626]],["t/1212",[145,4.568,269,4.517]],["t/1273",[17,2.683,18,3.434,270,5.219]],["t/1275",[145,4.568,269,4.517]],["t/1307",[112,5.166]],["t/1312",[17,2.525,18,3.231,19,3.231,20,4.251]],["t/1314",[28,1.735,116,2.396,271,4.911,272,4.911]],["t/1316",[4,3.603,273,4.013,274,4.013,275,4.637,276,4.013]],["t/1336",[109,3.438,277,4.661,278,3.972,279,3.972,280,3.972,281,3.972,282,3.972]],["t/1360",[17,2.145,82,2.035,283,4.172,284,4.172,285,4.172,286,4.172,287,3.241]],["t/1362",[17,2.042,144,3.438,288,3.972,289,3.438,290,3.972,291,3.972,292,3.972,293,3.972]],["t/1364",[294,5.968]],["t/1369",[12,2.695,19,2.495,50,2.06,87,2.695,88,2.695,195,3.282,295,3.791,296,3.791,297,3.791]],["t/1386",[4,3.603,273,4.013,274,4.013,276,4.013,298,4.637]],["t/1410",[16,2.614,17,2.042,299,3.972,300,3.972,301,3.972,302,3.972,303,3.972,304,3.972]],["t/1412",[2,2.946,17,1.949,82,1.849,305,3.791,306,3.282,307,3.791,308,3.791,309,3.791,310,3.791]],["t/1416",[2,2.591,55,2.591,80,2.591,82,1.627,210,2.591,287,2.591,289,2.887,306,2.887,311,2.887,312,3.335,313,3.335,314,3.335]],["t/1436",[17,1.786,103,2.7,210,2.7,277,3.007,287,2.7,311,3.007,315,3.475,316,3.475,317,3.475,318,3.475,319,3.475]]],"invertedIndex":[["",{"_index":145,"t":{"459":{"position":[[45,1]]},"512":{"position":[[41,1]]},"1212":{"position":[[0,2],[12,2]]},"1275":{"position":[[0,2],[12,2]]}}}],["14",{"_index":298,"t":{"1386":{"position":[[14,2]]}}}],["1459",{"_index":52,"t":{"168":{"position":[[14,4]]}}}],["2024",{"_index":4,"t":{"1":{"position":[[45,4]]},"1316":{"position":[[25,4]]},"1386":{"position":[[26,4]]}}}],["2025",{"_index":7,"t":{"1":{"position":[[70,5]]}}}],["9",{"_index":275,"t":{"1316":{"position":[[14,1]]}}}],["account",{"_index":248,"t":{"999":{"position":[[87,11]]}}}],["achiev",{"_index":3,"t":{"1":{"position":[[29,12]]},"659":{"position":[[58,8]]},"748":{"position":[[73,8]]}}}],["adapt",{"_index":246,"t":{"999":{"position":[[68,8]]}}}],["affili",{"_index":304,"t":{"1410":{"position":[[86,11]]}}}],["allow",{"_index":204,"t":{"792":{"position":[[44,8]]}}}],["along",{"_index":134,"t":{"409":{"position":[[55,5]]}}}],["altern",{"_index":262,"t":{"1129":{"position":[[68,11]]}}}],["ambient",{"_index":252,"t":{"1065":{"position":[[27,7]]}}}],["analysi",{"_index":268,"t":{"1170":{"position":[[55,8]]}}}],["anonym",{"_index":184,"t":{"714":{"position":[[52,9]]}}}],["app",{"_index":207,"t":{"821":{"position":[[66,4]]}}}],["appli",{"_index":183,"t":{"714":{"position":[[38,7]]}}}],["approach",{"_index":159,"t":{"512":{"position":[[51,8]]}}}],["architectur",{"_index":164,"t":{"530":{"position":[[43,13]]}}}],["archiv",{"_index":8,"t":{"57":{"position":[[0,7]]}}}],["area",{"_index":124,"t":{"333":{"position":[[130,6]]},"1065":{"position":[[117,5]]}}}],["articl",{"_index":155,"t":{"512":{"position":[[5,7]]}}}],["asynchron",{"_index":171,"t":{"669":{"position":[[16,12]]}}}],["bandwidth",{"_index":228,"t":{"941":{"position":[[22,9]]}}}],["base",{"_index":55,"t":{"168":{"position":[[43,5]]},"333":{"position":[[25,5]]},"1416":{"position":[[94,4]]}}}],["basic",{"_index":264,"t":{"1170":{"position":[[14,5]]}}}],["behind",{"_index":71,"t":{"213":{"position":[[46,6]]}}}],["benefit",{"_index":53,"t":{"168":{"position":[[27,8]]}}}],["better",{"_index":43,"t":{"120":{"position":[[344,6]]},"999":{"position":[[52,6]]}}}],["blockchain",{"_index":140,"t":{"421":{"position":[[27,10]]}}}],["blog",{"_index":154,"t":{"491":{"position":[[0,4]]},"606":{"position":[[0,4]]},"627":{"position":[[0,4]]},"648":{"position":[[0,4]]}}}],["bloom",{"_index":213,"t":{"852":{"position":[[32,5]]}}}],["bottleneck",{"_index":211,"t":{"838":{"position":[[95,12]]}}}],["bring",{"_index":166,"t":{"659":{"position":[[11,8]]}}}],["browser",{"_index":167,"t":{"659":{"position":[[35,8]]}}}],["build",{"_index":26,"t":{"120":{"position":[[76,5],[429,5]]}}}],["censorship",{"_index":260,"t":{"1129":{"position":[[38,10]]}}}],["central",{"_index":194,"t":{"748":{"position":[[184,11]]}}}],["centric",{"_index":161,"t":{"530":{"position":[[18,7]]}}}],["chang",{"_index":281,"t":{"1336":{"position":[[102,7]]}}}],["client",{"_index":117,"t":{"333":{"position":[[39,7]]}}}],["collect",{"_index":293,"t":{"1362":{"position":[[60,11]]}}}],["come",{"_index":250,"t":{"1045":{"position":[[122,6]]}}}],["common",{"_index":216,"t":{"878":{"position":[[29,6]]}}}],["commun",{"_index":18,"t":{"105":{"position":[[6,14]]},"120":{"position":[[110,13]]},"821":{"position":[[16,13]]},"1273":{"position":[[13,10]]},"1312":{"position":[[6,14]]}}}],["comparison",{"_index":227,"t":{"941":{"position":[[8,10]]}}}],["compon",{"_index":314,"t":{"1416":{"position":[[99,10]]}}}],["comprehens",{"_index":317,"t":{"1436":{"position":[[49,13]]}}}],["conduct",{"_index":283,"t":{"1360":{"position":[[13,8]]}}}],["contribut",{"_index":112,"t":{"323":{"position":[[118,10]]},"1307":{"position":[[7,10]]}}}],["convert",{"_index":218,"t":{"878":{"position":[[54,7]]}}}],["cornerston",{"_index":292,"t":{"1362":{"position":[[35,11]]}}}],["cover",{"_index":147,"t":{"459":{"position":[[60,8]]},"748":{"position":[[138,5]]}}}],["crucial",{"_index":57,"t":{"170":{"position":[[29,7]]}}}],["cuckoo",{"_index":215,"t":{"852":{"position":[[50,6]]}}}],["current",{"_index":122,"t":{"333":{"position":[[105,7]]},"838":{"position":[[27,7]]},"1065":{"position":[[58,9]]}}}],["data",{"_index":58,"t":{"170":{"position":[[37,4]]},"852":{"position":[[15,4]]}}}],["de",{"_index":10,"t":{"58":{"position":[[21,2]]}}}],["decentr",{"_index":12,"t":{"58":{"position":[[31,13]]},"469":{"position":[[29,14]]},"821":{"position":[[52,13]]},"1369":{"position":[[48,13]]}}}],["design",{"_index":100,"t":{"303":{"position":[[45,6]]},"388":{"position":[[23,6]]},"1099":{"position":[[68,6]]}}}],["detail",{"_index":136,"t":{"409":{"position":[[97,9]]},"748":{"position":[[243,7]]}}}],["develop",{"_index":80,"t":{"235":{"position":[[95,11]]},"333":{"position":[[77,12]]},"1416":{"position":[[83,10]]}}}],["devic",{"_index":46,"t":{"160":{"position":[[0,6]]},"684":{"position":[[24,7]]}}}],["differ",{"_index":38,"t":{"120":{"position":[[286,9]]},"409":{"position":[[151,7]]}}}],["discoveri",{"_index":56,"t":{"168":{"position":[[49,10]]},"409":{"position":[[19,9]]},"1065":{"position":[[40,9]]}}}],["discuss",{"_index":200,"t":{"748":{"position":[[328,9]]},"1065":{"position":[[16,10]]}}}],["discv4",{"_index":135,"t":{"409":{"position":[[78,6]]}}}],["discv5",{"_index":68,"t":{"213":{"position":[[11,6]]},"409":{"position":[[89,7]]}}}],["dissemin",{"_index":101,"t":{"303":{"position":[[64,13]]}}}],["divers",{"_index":78,"t":{"235":{"position":[[77,7]]}}}],["dn",{"_index":54,"t":{"168":{"position":[[39,3]]}}}],["doesn't",{"_index":94,"t":{"282":{"position":[[28,7]]}}}],["driven",{"_index":315,"t":{"1436":{"position":[[19,6]]}}}],["dynam",{"_index":205,"t":{"792":{"position":[[53,7]]}}}],["easier",{"_index":37,"t":{"120":{"position":[[264,6]]}}}],["econom",{"_index":197,"t":{"748":{"position":[[258,8]]}}}],["ecosystem",{"_index":79,"t":{"235":{"position":[[85,9]]}}}],["edit",{"_index":143,"t":{"459":{"position":[[21,7]]}}}],["effici",{"_index":180,"t":{"684":{"position":[[63,12]]},"1099":{"position":[[75,9]]}}}],["effort",{"_index":310,"t":{"1412":{"position":[[78,8]]}}}],["eip",{"_index":51,"t":{"168":{"position":[[10,3]]}}}],["emerg",{"_index":307,"t":{"1412":{"position":[[27,8]]}}}],["emphas",{"_index":129,"t":{"388":{"position":[[30,10]]}}}],["end",{"_index":201,"t":{"748":{"position":[[345,4]]}}}],["environ",{"_index":39,"t":{"120":{"position":[[296,13]]}}}],["epoch",{"_index":206,"t":{"792":{"position":[[61,5]]}}}],["etc",{"_index":20,"t":{"105":{"position":[[30,4]]},"1312":{"position":[[30,4]]}}}],["ethereum",{"_index":225,"t":{"906":{"position":[[162,9]]},"970":{"position":[[17,8]]}}}],["etherum",{"_index":241,"t":{"970":{"position":[[138,7]]}}}],["ethic",{"_index":62,"t":{"194":{"position":[[18,7]]}}}],["evolut",{"_index":98,"t":{"303":{"position":[[24,9]]}}}],["evolv",{"_index":75,"t":{"235":{"position":[[30,8]]}}}],["examin",{"_index":212,"t":{"852":{"position":[[3,7]]}}}],["exchang",{"_index":48,"t":{"160":{"position":[[34,8]]},"1099":{"position":[[100,8]]}}}],["explor",{"_index":285,"t":{"1360":{"position":[[33,11]]}}}],["far",{"_index":168,"t":{"659":{"position":[[70,3]]}}}],["fast",{"_index":179,"t":{"684":{"position":[[54,4]]}}}],["featur",{"_index":149,"t":{"459":{"position":[[79,8]]}}}],["februari",{"_index":276,"t":{"1316":{"position":[[16,8]]},"1386":{"position":[[17,8]]}}}],["filter",{"_index":214,"t":{"852":{"position":[[38,7],[57,8]]}}}],["find",{"_index":72,"t":{"213":{"position":[[53,7]]},"970":{"position":[[45,4]]},"1045":{"position":[[27,4]]}}}],["first",{"_index":139,"t":{"421":{"position":[[21,5]]},"459":{"position":[[15,5]]}}}],["fix",{"_index":95,"t":{"282":{"position":[[53,3]]}}}],["focu",{"_index":123,"t":{"333":{"position":[[124,5]]},"388":{"position":[[63,5]]},"740":{"position":[[54,5]]}}}],["forward",{"_index":6,"t":{"1":{"position":[[59,7]]}}}],["framework",{"_index":253,"t":{"1099":{"position":[[45,9]]}}}],["free",{"_index":302,"t":{"1410":{"position":[[62,4]]}}}],["further",{"_index":111,"t":{"323":{"position":[[110,7]]}}}],["futur",{"_index":81,"t":{"235":{"position":[[120,6]]},"333":{"position":[[117,6]]},"748":{"position":[[311,6]]},"1065":{"position":[[96,6]]}}}],["gain",{"_index":113,"t":{"323":{"position":[[144,6]]}}}],["give",{"_index":192,"t":{"748":{"position":[[22,4]]}}}],["global",{"_index":64,"t":{"194":{"position":[[44,6]]}}}],["go",{"_index":191,"t":{"748":{"position":[[13,5]]},"1045":{"position":[[44,5]]}}}],["goal",{"_index":222,"t":{"906":{"position":[[39,6]]}}}],["gossipsub",{"_index":96,"t":{"303":{"position":[[0,9]]},"367":{"position":[[26,10]]},"388":{"position":[[13,9]]}}}],["handl",{"_index":126,"t":{"367":{"position":[[14,8]]}}}],["happen",{"_index":249,"t":{"1045":{"position":[[103,10]]}}}],["highlight",{"_index":108,"t":{"323":{"position":[[77,10]]}}}],["histori",{"_index":133,"t":{"409":{"position":[[8,7]]}}}],["hope",{"_index":41,"t":{"120":{"position":[[332,4]]}}}],["https://our.status.im/our",{"_index":279,"t":{"1336":{"position":[[42,25]]}}}],["idontw",{"_index":106,"t":{"323":{"position":[[43,9]]}}}],["ift",{"_index":287,"t":{"1360":{"position":[[56,4]]},"1416":{"position":[[51,3]]},"1436":{"position":[[84,3]]}}}],["implement",{"_index":223,"t":{"906":{"position":[[57,14]]}}}],["import",{"_index":45,"t":{"120":{"position":[[366,10]]}}}],["improv",{"_index":97,"t":{"303":{"position":[[10,13]]},"367":{"position":[[47,12]]},"792":{"position":[[0,9]]},"941":{"position":[[63,8]]}}}],["incentiv",{"_index":33,"t":{"120":{"position":[[170,11]]},"235":{"position":[[56,16]]}}}],["includ",{"_index":118,"t":{"333":{"position":[[47,9]]}}}],["incub",{"_index":305,"t":{"1412":{"position":[[4,9]]}}}],["industri",{"_index":67,"t":{"194":{"position":[[69,9]]}}}],["infrastructur",{"_index":24,"t":{"120":{"position":[[27,15],[399,14]]},"821":{"position":[[75,14]]}}}],["inherit",{"_index":278,"t":{"1336":{"position":[[27,9]]}}}],["initi",{"_index":308,"t":{"1412":{"position":[[36,11]]}}}],["innov",{"_index":284,"t":{"1360":{"position":[[22,10]]}}}],["insight",{"_index":105,"t":{"323":{"position":[[25,8]]}}}],["institut",{"_index":301,"t":{"1410":{"position":[[49,9]]}}}],["integr",{"_index":313,"t":{"1416":{"position":[[28,8]]}}}],["interact",{"_index":219,"t":{"878":{"position":[[62,11]]}}}],["introduc",{"_index":9,"t":{"58":{"position":[[10,10]]},"170":{"position":[[17,9]]},"333":{"position":[[0,11]]},"512":{"position":[[13,10]]},"878":{"position":[[17,9]]},"1065":{"position":[[0,11]]},"1170":{"position":[[0,11]]}}}],["issu",{"_index":198,"t":{"748":{"position":[[300,6]]}}}],["join",{"_index":270,"t":{"1273":{"position":[[0,4]]}}}],["journey",{"_index":239,"t":{"970":{"position":[[64,7]]}}}],["js",{"_index":165,"t":{"659":{"position":[[0,2]]}}}],["key",{"_index":255,"t":{"1099":{"position":[[96,3]]}}}],["knowledg",{"_index":85,"t":{"255":{"position":[[21,9]]}}}],["larg",{"_index":125,"t":{"367":{"position":[[0,5]]}}}],["last",{"_index":273,"t":{"1316":{"position":[[0,4]]},"1386":{"position":[[0,4]]}}}],["layer",{"_index":15,"t":{"58":{"position":[[64,5]]},"120":{"position":[[124,5]]}}}],["learn",{"_index":74,"t":{"235":{"position":[[0,5]]},"659":{"position":[[44,5]]},"906":{"position":[[0,5]]}}}],["less",{"_index":131,"t":{"388":{"position":[[58,4]]}}}],["libp2p",{"_index":244,"t":{"999":{"position":[[44,7]]}}}],["librari",{"_index":35,"t":{"120":{"position":[[242,7]]}}}],["limit",{"_index":88,"t":{"255":{"position":[[51,8]]},"714":{"position":[[5,8]]},"748":{"position":[[109,8]]},"1369":{"position":[[26,8]]}}}],["local",{"_index":226,"t":{"941":{"position":[[2,5]]}}}],["log",{"_index":83,"t":{"255":{"position":[[11,4]]},"282":{"position":[[11,4]]},"469":{"position":[[11,4]]},"669":{"position":[[11,4],[51,4]]},"838":{"position":[[11,4]]},"1045":{"position":[[11,4]]}}}],["logo",{"_index":144,"t":{"459":{"position":[[39,5],[93,6]]},"1362":{"position":[[54,5]]}}}],["look",{"_index":5,"t":{"1":{"position":[[54,4]]},"120":{"position":[[92,4],[223,4]]},"168":{"position":[[2,4]]},"194":{"position":[[2,4]]},"213":{"position":[[0,7]]},"235":{"position":[[133,4]]},"409":{"position":[[68,4]]},"1129":{"position":[[90,4]]}}}],["made",{"_index":282,"t":{"1336":{"position":[[120,4]]}}}],["major",{"_index":148,"t":{"459":{"position":[[69,5]]}}}],["make",{"_index":36,"t":{"120":{"position":[[255,5]]}}}],["mani",{"_index":209,"t":{"838":{"position":[[54,4]]}}}],["mdsecheck",{"_index":156,"t":{"512":{"position":[[24,9]]}}}],["mechan",{"_index":89,"t":{"255":{"position":[[60,9]]},"1099":{"position":[[109,10]]}}}],["meetup",{"_index":237,"t":{"970":{"position":[[26,7]]}}}],["messag",{"_index":14,"t":{"58":{"position":[[56,7]]},"160":{"position":[[26,7]]},"303":{"position":[[56,7]]},"323":{"position":[[53,7]]},"367":{"position":[[6,7]]},"388":{"position":[[72,7]]},"669":{"position":[[33,10]]},"740":{"position":[[30,9],[70,10]]},"906":{"position":[[149,9]]},"970":{"position":[[146,10]]},"1045":{"position":[[69,9]]}}}],["method",{"_index":157,"t":{"512":{"position":[[34,6]]},"748":{"position":[[173,7],[283,7]]},"1065":{"position":[[50,7]]}}}],["minor",{"_index":109,"t":{"323":{"position":[[88,5]]},"1336":{"position":[[86,5]]}}}],["ml",{"_index":11,"t":{"58":{"position":[[24,4],[79,5]]}}}],["model",{"_index":266,"t":{"1170":{"position":[[27,5]]}}}],["modular",{"_index":185,"t":{"740":{"position":[[9,7]]}}}],["more",{"_index":221,"t":{"906":{"position":[[6,4]]}}}],["move",{"_index":243,"t":{"999":{"position":[[34,6]]}}}],["need",{"_index":25,"t":{"120":{"position":[[53,4]]}}}],["nescienc",{"_index":138,"t":{"421":{"position":[[0,10]]},"530":{"position":[[0,10]]}}}],["network",{"_index":34,"t":{"120":{"position":[[203,8]]},"235":{"position":[[19,7]]},"255":{"position":[[93,9]]},"303":{"position":[[98,8]]},"409":{"position":[[45,9]]},"714":{"position":[[66,8]]},"821":{"position":[[43,8]]}}}],["newslett",{"_index":146,"t":{"459":{"position":[[49,10]]}}}],["next",{"_index":169,"t":{"659":{"position":[[86,4]]},"838":{"position":[[115,5]]},"1045":{"position":[[132,5]]}}}],["nim",{"_index":115,"t":{"333":{"position":[[21,3]]},"459":{"position":[[32,3],[75,3]]}}}],["node",{"_index":247,"t":{"999":{"position":[[77,5]]}}}],["nois",{"_index":49,"t":{"160":{"position":[[58,5]]},"1099":{"position":[[30,5]]}}}],["noninteract",{"_index":220,"t":{"878":{"position":[[93,14]]}}}],["novel",{"_index":158,"t":{"512":{"position":[[45,5]]}}}],["nullifi",{"_index":181,"t":{"714":{"position":[[14,10]]},"748":{"position":[[118,11]]}}}],["number",{"_index":70,"t":{"213":{"position":[[38,7]]}}}],["nwaku",{"_index":114,"t":{"333":{"position":[[12,6]]}}}],["ongo",{"_index":224,"t":{"906":{"position":[[76,7]]}}}],["open",{"_index":189,"t":{"740":{"position":[[110,4]]},"748":{"position":[[295,4]]},"821":{"position":[[11,4]]},"1129":{"position":[[63,4]]}}}],["origin",{"_index":128,"t":{"388":{"position":[[4,8]]},"906":{"position":[[30,8]]}}}],["out",{"_index":238,"t":{"970":{"position":[[50,3]]},"1045":{"position":[[32,3]]}}}],["over",{"_index":233,"t":{"941":{"position":[[95,4]]}}}],["overlay",{"_index":99,"t":{"303":{"position":[[37,7]]}}}],["overview",{"_index":187,"t":{"740":{"position":[[81,8]]},"748":{"position":[[34,8],[230,8]]},"1099":{"position":[[14,8]]}}}],["p2p",{"_index":92,"t":{"255":{"position":[[89,3]]},"303":{"position":[[94,3]]},"669":{"position":[[29,3]]},"714":{"position":[[62,3]]},"748":{"position":[[200,3]]}}}],["pair",{"_index":47,"t":{"160":{"position":[[7,7]]}}}],["paper",{"_index":294,"t":{"1364":{"position":[[0,6]]}}}],["peer",{"_index":73,"t":{"213":{"position":[[61,6]]},"409":{"position":[[32,4],[40,4]]},"740":{"position":[[17,4],[25,4]]},"1065":{"position":[[35,4]]}}}],["perform",{"_index":107,"t":{"323":{"position":[[61,11],[132,11]]}}}],["perspect",{"_index":150,"t":{"459":{"position":[[100,12]]}}}],["pick",{"_index":152,"t":{"469":{"position":[[44,4]]}}}],["pipelin",{"_index":170,"t":{"659":{"position":[[98,9]]}}}],["plan",{"_index":242,"t":{"999":{"position":[[15,5]]},"1065":{"position":[[103,5]]}}}],["post",{"_index":0,"t":{"1":{"position":[[8,5]]},"58":{"position":[[5,4]]},"170":{"position":[[8,5]]},"323":{"position":[[5,4]]},"748":{"position":[[5,4]]},"878":{"position":[[8,5]]}}}],["potenti",{"_index":127,"t":{"367":{"position":[[37,9]]}}}],["power",{"_index":296,"t":{"1369":{"position":[[71,7]]}}}],["practic",{"_index":182,"t":{"714":{"position":[[28,9]]}}}],["preserv",{"_index":295,"t":{"1369":{"position":[[10,10]]}}}],["prevent",{"_index":90,"t":{"255":{"position":[[73,7]]}}}],["preview",{"_index":121,"t":{"333":{"position":[[94,7]]}}}],["previou",{"_index":202,"t":{"792":{"position":[[17,8]]}}}],["principl",{"_index":277,"t":{"1336":{"position":[[6,10],[68,12]]},"1436":{"position":[[9,9]]}}}],["privaci",{"_index":19,"t":{"105":{"position":[[21,8]]},"120":{"position":[[8,7],[380,7]]},"421":{"position":[[13,7]]},"1312":{"position":[[21,8]]},"1369":{"position":[[2,7]]}}}],["privacy/anonym",{"_index":267,"t":{"1170":{"position":[[37,17]]}}}],["privat",{"_index":259,"t":{"1129":{"position":[[29,8]]}}}],["problem",{"_index":190,"t":{"740":{"position":[[115,9]]}}}],["profil",{"_index":229,"t":{"941":{"position":[[32,8]]}}}],["project",{"_index":306,"t":{"1412":{"position":[[14,8]]},"1416":{"position":[[55,8]]}}}],["proof",{"_index":178,"t":{"684":{"position":[[47,6]]}}}],["protect",{"_index":23,"t":{"120":{"position":[[16,10],[186,7],[388,10]]},"748":{"position":[[55,10],[162,10],[272,10]]}}}],["protocol",{"_index":50,"t":{"160":{"position":[[64,9]]},"821":{"position":[[30,8]]},"878":{"position":[[74,9]]},"906":{"position":[[46,10]]},"1045":{"position":[[79,9]]},"1099":{"position":[[36,8]]},"1170":{"position":[[86,9]]},"1369":{"position":[[35,8]]}}}],["provid",{"_index":103,"t":{"323":{"position":[[10,8]]},"1099":{"position":[[3,7]]},"1436":{"position":[[40,8]]}}}],["quick",{"_index":104,"t":{"323":{"position":[[19,5]]},"409":{"position":[[2,5]]}}}],["r&d",{"_index":311,"t":{"1416":{"position":[[6,3]]},"1436":{"position":[[26,3]]}}}],["rate",{"_index":87,"t":{"255":{"position":[[46,4]]},"714":{"position":[[0,4]]},"748":{"position":[[104,4]]},"1369":{"position":[[21,4]]}}}],["read",{"_index":40,"t":{"120":{"position":[[316,7]]},"970":{"position":[[34,4]]},"999":{"position":[[0,4]]},"1045":{"position":[[16,4]]}}}],["recap",{"_index":1,"t":{"1":{"position":[[17,5]]}}}],["recent",{"_index":120,"t":{"333":{"position":[[70,6]]}}}],["relay",{"_index":193,"t":{"748":{"position":[[90,5]]},"1170":{"position":[[80,5]]}}}],["reliabl",{"_index":151,"t":{"469":{"position":[[16,8]]}}}],["remot",{"_index":172,"t":{"669":{"position":[[44,6]]}}}],["rescu",{"_index":173,"t":{"669":{"position":[[63,7]]}}}],["research",{"_index":82,"t":{"255":{"position":[[2,8]]},"282":{"position":[[2,8]]},"469":{"position":[[2,8]]},"669":{"position":[[2,8]]},"838":{"position":[[2,8]]},"906":{"position":[[84,9]]},"1045":{"position":[[2,8]]},"1360":{"position":[[4,8]]},"1412":{"position":[[69,8]]},"1416":{"position":[[67,11]]}}}],["resist",{"_index":261,"t":{"1129":{"position":[[49,9]]}}}],["resourc",{"_index":174,"t":{"684":{"position":[[4,8]]}}}],["restrict",{"_index":175,"t":{"684":{"position":[[13,10]]}}}],["rfc",{"_index":288,"t":{"1362":{"position":[[8,3]]}}}],["rln",{"_index":177,"t":{"684":{"position":[[43,3]]},"792":{"position":[[37,3]]}}}],["robust",{"_index":130,"t":{"388":{"position":[[41,11]]}}}],["rout",{"_index":245,"t":{"999":{"position":[[59,8]]}}}],["scalabl",{"_index":232,"t":{"941":{"position":[[72,11]]}}}],["scale",{"_index":77,"t":{"235":{"position":[[47,8]]},"282":{"position":[[36,5]]}}}],["secur",{"_index":16,"t":{"58":{"position":[[70,8]]},"160":{"position":[[19,6]]},"740":{"position":[[63,6]]},"1099":{"position":[[89,6]]},"1410":{"position":[[8,8]]}}}],["see",{"_index":30,"t":{"120":{"position":[[146,3]]}}}],["self",{"_index":257,"t":{"1129":{"position":[[13,4]]}}}],["separ",{"_index":163,"t":{"530":{"position":[[32,10]]}}}],["serious",{"_index":300,"t":{"1410":{"position":[[17,9]]}}}],["serv",{"_index":290,"t":{"1362":{"position":[[17,6]]}}}],["servic",{"_index":312,"t":{"1416":{"position":[[10,7]]}}}],["session",{"_index":272,"t":{"1314":{"position":[[17,7]]}}}],["shortfal",{"_index":63,"t":{"194":{"position":[[26,10]]}}}],["show",{"_index":230,"t":{"941":{"position":[[41,7]]}}}],["signal",{"_index":86,"t":{"255":{"position":[[31,9]]}}}],["significantli",{"_index":231,"t":{"941":{"position":[[49,13]]}}}],["size",{"_index":132,"t":{"388":{"position":[[80,6]]},"792":{"position":[[67,6]]}}}],["solut",{"_index":196,"t":{"748":{"position":[[221,8]]}}}],["sovereign",{"_index":258,"t":{"1129":{"position":[[18,10]]}}}],["spam",{"_index":91,"t":{"255":{"position":[[81,4]]},"748":{"position":[[50,4],[157,4],[267,4]]}}}],["stack",{"_index":186,"t":{"740":{"position":[[40,6],[100,5]]}}}],["startup",{"_index":319,"t":{"1436":{"position":[[88,9]]}}}],["state",{"_index":162,"t":{"530":{"position":[[26,5]]},"838":{"position":[[35,5]]}}}],["stem",{"_index":309,"t":{"1412":{"position":[[53,4]]}}}],["step",{"_index":199,"t":{"748":{"position":[[318,5]]}}}],["structur",{"_index":59,"t":{"170":{"position":[[42,9]]},"852":{"position":[[20,11]]}}}],["stylist",{"_index":280,"t":{"1336":{"position":[[92,9]]}}}],["summari",{"_index":119,"t":{"333":{"position":[[59,7]]},"748":{"position":[[146,7]]}}}],["support",{"_index":210,"t":{"838":{"position":[[73,8]]},"1416":{"position":[[40,10]]},"1436":{"position":[[73,7]]}}}],["surveil",{"_index":65,"t":{"194":{"position":[[51,12]]}}}],["system",{"_index":195,"t":{"748":{"position":[[204,8]]},"1369":{"position":[[62,8]]}}}],["taipei",{"_index":236,"t":{"970":{"position":[[10,6]]}}}],["take",{"_index":299,"t":{"1410":{"position":[[3,4]]}}}],["talk",{"_index":235,"t":{"970":{"position":[[0,4]]}}}],["team",{"_index":316,"t":{"1436":{"position":[[30,4]]}}}],["tech",{"_index":66,"t":{"194":{"position":[[64,4]]}}}],["technic",{"_index":318,"t":{"1436":{"position":[[63,9]]}}}],["techniqu",{"_index":217,"t":{"878":{"position":[[36,9]]}}}],["technolog",{"_index":303,"t":{"1410":{"position":[[67,10]]}}}],["term",{"_index":188,"t":{"740":{"position":[[93,6]]}}}],["theoret",{"_index":69,"t":{"213":{"position":[[26,11]]}}}],["threat",{"_index":265,"t":{"1170":{"position":[[20,6]]}}}],["through",{"_index":76,"t":{"235":{"position":[[39,7]]},"748":{"position":[[96,7]]}}}],["throughout",{"_index":60,"t":{"170":{"position":[[57,10]]}}}],["tool",{"_index":254,"t":{"1099":{"position":[[60,4]]}}}],["toolkit",{"_index":22,"t":{"106":{"position":[[13,7]]}}}],["train",{"_index":271,"t":{"1314":{"position":[[8,8]]}}}],["truncat",{"_index":269,"t":{"1212":{"position":[[3,8]]},"1275":{"position":[[3,8]]}}}],["tweak",{"_index":110,"t":{"323":{"position":[[94,6]]}}}],["two",{"_index":153,"t":{"469":{"position":[[49,4]]},"852":{"position":[[11,3]]}}}],["typic",{"_index":61,"t":{"194":{"position":[[10,7]]}}}],["understand",{"_index":44,"t":{"120":{"position":[[351,10]]},"906":{"position":[[94,10]]}}}],["unit",{"_index":289,"t":{"1362":{"position":[[12,4]]},"1416":{"position":[[18,5]]}}}],["unstructur",{"_index":102,"t":{"303":{"position":[[81,12]]}}}],["up",{"_index":251,"t":{"1045":{"position":[[129,2]]}}}],["updat",{"_index":274,"t":{"1316":{"position":[[5,8]]},"1386":{"position":[[5,8]]}}}],["us",{"_index":31,"t":{"120":{"position":[[157,4],[274,3]]},"160":{"position":[[43,5]]},"170":{"position":[[52,4]]},"821":{"position":[[94,3]]},"878":{"position":[[46,4]]},"906":{"position":[[115,4],[138,6]]},"970":{"position":[[127,6]]},"1065":{"position":[[68,4]]}}}],["user",{"_index":160,"t":{"530":{"position":[[13,4]]},"838":{"position":[[59,5]]}}}],["v1",{"_index":234,"t":{"941":{"position":[[105,3]]}}}],["v2",{"_index":116,"t":{"333":{"position":[[36,2]]},"659":{"position":[[25,2]]},"906":{"position":[[22,3]]},"941":{"position":[[92,2]]},"970":{"position":[[93,3],[117,2]]},"999":{"position":[[30,3]]},"1045":{"position":[[63,3]]},"1065":{"position":[[81,3]]},"1170":{"position":[[77,2]]},"1314":{"position":[[5,2]]}}}],["vac",{"_index":17,"t":{"105":{"position":[[0,3]]},"740":{"position":[[0,3]]},"1273":{"position":[[9,3]]},"1312":{"position":[[0,3]]},"1360":{"position":[[0,3]]},"1362":{"position":[[4,3]]},"1410":{"position":[[30,3]]},"1412":{"position":[[0,3]]},"1436":{"position":[[0,3]]}}}],["vac'",{"_index":2,"t":{"1":{"position":[[23,5]]},"1412":{"position":[[63,5]]},"1416":{"position":[[0,5]]}}}],["variant",{"_index":13,"t":{"58":{"position":[[45,7]]},"878":{"position":[[108,8]]}}}],["verifi",{"_index":176,"t":{"684":{"position":[[36,6]]}}}],["version",{"_index":203,"t":{"792":{"position":[[26,7]]}}}],["vital",{"_index":291,"t":{"1362":{"position":[[29,5]]}}}],["waku",{"_index":28,"t":{"120":{"position":[[100,5],[198,4]]},"160":{"position":[[49,4]]},"235":{"position":[[14,4]]},"333":{"position":[[31,4]]},"659":{"position":[[3,4],[20,4]]},"714":{"position":[[80,5]]},"748":{"position":[[85,4]]},"821":{"position":[[0,4],[98,4]]},"838":{"position":[[44,5]]},"906":{"position":[[17,4]]},"941":{"position":[[87,4],[100,4]]},"970":{"position":[[88,4],[112,4]]},"999":{"position":[[25,4]]},"1045":{"position":[[58,4]]},"1065":{"position":[[76,4]]},"1170":{"position":[[72,4]]},"1314":{"position":[[0,4]]}}}],["waku2",{"_index":256,"t":{"1099":{"position":[[123,6]]}}}],["we'll",{"_index":27,"t":{"120":{"position":[[86,5],[140,5],[212,5]]}}}],["web3",{"_index":29,"t":{"120":{"position":[[134,5]]},"170":{"position":[[68,5]]}}}],["wechat",{"_index":263,"t":{"1129":{"position":[[83,6]]}}}],["welcom",{"_index":142,"t":{"459":{"position":[[0,7]]}}}],["well",{"_index":240,"t":{"970":{"position":[[100,4]]},"1065":{"position":[[88,4]]}}}],["what'",{"_index":208,"t":{"838":{"position":[[16,6],[108,6]]}}}],["whisper",{"_index":93,"t":{"282":{"position":[[20,7]]},"970":{"position":[[77,7]]}}}],["within",{"_index":286,"t":{"1360":{"position":[[45,6]]}}}],["work",{"_index":137,"t":{"409":{"position":[[131,4]]}}}],["you'll",{"_index":42,"t":{"120":{"position":[[337,6]]}}}],["zero",{"_index":84,"t":{"255":{"position":[[16,4]]}}}],["zerokit",{"_index":21,"t":{"106":{"position":[[0,7]]},"120":{"position":[[231,8]]}}}],["zk",{"_index":297,"t":{"1369":{"position":[[82,3]]}}}],["zkp",{"_index":32,"t":{"120":{"position":[[162,4],[278,4]]}}}],["zkvm",{"_index":141,"t":{"421":{"position":[[38,5]]}}}]],"pipeline":["stemmer"]}},{"documents":[],"index":{"version":"2.3.9","fields":["t"],"fieldVectors":[],"invertedIndex":[],"pipeline":["stemmer"]}},{"documents":[{"i":2,"t":"In this post, we recap Vac's achievements in 2024 and look forward to 2025. With 2024 now behind us and a new year ahead, Vac is proud to reflect on the milestones and breakthroughs that defined another year of researching and developing free and open digital public goods for the Institute of Free Technology and wider web3 ecosystem. Vac comprises various subteams and service units, each with its own focus. Below, we celebrate each unit's achievements and look forward to its 2025 plans.","s":"Vac 2024 Year in Review","u":"/rlog/2024-recap","h":"","p":1},{"i":4,"t":"Nescience is our state separation architecture that aims to enable private transactions and provide a general-purpose execution environment for classical applications.","s":"Nescience","u":"/rlog/2024-recap","h":"#nescience","p":1},{"i":6,"t":"This year, the Nescience state separation architecture moved from exploration to real progress, taking significant steps towards building a functional and reliable system. The team focused on turning ideas into something real, testing the proposed architecture, and understanding its strengths and weaknesses. ZkVM exploration and benchmarks Published deep reviews of 23 existing zkVMs Benchmarked the performance of the six zkVMs that best fit Nescience Defined the NSSA architecture Brought clarity to NSSA’s design and explained the system’s architecture in a lengthy exploratory blog post Built the sandboxed testnet Designed the first version of the node specification All core components (execution types, UTXOs, cryptographic primitives) implemented and being tested Testing the performance of all execution types in various scenarios We also made progress on the essential parts of NSSA’s system, including: Key protocol for secure key management Execution types and circuits for reliable computation UTXO specification to manage state transitions effectively Cryptography module to ensure privacy and security","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights","p":1},{"i":8,"t":"In 2025, the Nescience team plans to double down on what works, fix what doesn’t, and push NSSA closer to real-world use. Sandboxed testnet data analysis – the sandboxed testnet will be our primary data source that we will analyse to identify issues, limitations, and areas for improvement. Expanding the node – expand sandboxed components into a full node implementation with rigorous testing and iterative optimization (to bridge the gap between proof of concept and production readiness). Finalizing the architecture and RFC – after completing NSSA’s architecture, we will draft an RFC to ensure transparency and enable greater collaboration with the broader ecosystem. Testing real-life scenarios – applying NSSA to diverse, practical use cases to assess its adaptability, performance, and impact. Ongoing optimization – ensure NSSA is robust, efficient, and ready to scale.","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward","p":1},{"i":10,"t":"The TKE Service Unit works closely with IFT portfolio projects to design and implement crypto-economic incentive structures.","s":"Token Economics (TKE)","u":"/rlog/2024-recap","h":"#token-economics-tke","p":1},{"i":12,"t":"Formalized and implemented Codex economic incentives in the Litepaper and simulations Orchestrated Status Network incentive structure and smart contract implementation Started building Nomos’s economic model Consulted and provided analysis of incentives for the Logos Operators ordinals project Drove discussions on the economic sustainability of Waku; helped define RLN membership and its payment mechanism","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-1","p":1},{"i":14,"t":"In 2025, TKE will continue to support IFT portfolio projects, working toward economic sustainability while strengthening relationships within the organization. Additionally, the service unit aims to continue building its external reputation through partnerships and publications of relevant work on the Vac forum.","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-1","p":1},{"i":16,"t":"The QA Service Unit focuses on the development and execution of comprehensive test plans, including implementing unit and interoperability testing.","s":"Quality Assurance (QA)","u":"/rlog/2024-recap","h":"#quality-assurance-qa","p":1},{"i":18,"t":"Matured Waku interoperability testing framework with coverage for all major protocols and features Began collaboration with Nomos, contributing to unit and integration testing Partnered with the Status team to test message reliability under unstable network conditions","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-2","p":1},{"i":20,"t":"Extend collaboration with the Waku team on go-waku bindings and message reliability testing Cement working relationship with the Nomos team through the building of an E2E testing framework for higher-level node validation Work closely with Status’s QA team to enhance the functional testing framework Continue work on nim-libp2p testing Expand collaboration to additional projects","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-2","p":1},{"i":22,"t":"The RFC Service Unit takes on the responsibility of shepherding and editing specifications for IFT projects. The unit acts as a linchpin for ensuring standardized and interoperable protocols within the IFT ecosystem.","s":"RFC","u":"/rlog/2024-recap","h":"#rfc","p":1},{"i":24,"t":"Working to implement RFC culture across the IFT ecosystem Began editorial work for several IFT portfolio projects: Status, Nomos, Waku, and Codex. Reworked our standards with regard to writing RFCs to a consensus-oriented specification system","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-3","p":1},{"i":26,"t":"Continue to implement RFC culture across the IFT ecosystem Broaden the number of RFCs produced – particularly for IFT portfolio projects nearing public releases Include new projects with the rfc-index Encourage external projects requiring RFCs to establish relationships with the service unit","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-3","p":1},{"i":28,"t":"The ACZ Service Unit focuses on cryptographic solutions and zero-knowledge proofs, enhancing the security, privacy, and trustworthiness of IFT portfolio projects and contributing to the overall integrity and resilience of the decentralized web ecosystem.","s":"Applied Cryptography and ZK (ACZ)","u":"/rlog/2024-recap","h":"#applied-cryptography-and-zk-acz","p":1},{"i":30,"t":"Researched a libp2p mix protocol and first proof-of-concept implementation (including ping and GossipSub over mix) Researched a decentralized version of MLS (message layer security) with a first proof of concept Released Zerokit v0.6.0 and v0.5.0 Added gnark RLN implementation Released Stealth Address Kit v0.3.1, v0.2.0, and v0.1.0 Published: Verifying RLN Proofs in Light Clients with Subtrees RLN-v3: Towards a Flexible and Cost-Efficient Implementation","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-4","p":1},{"i":32,"t":"Ensure libp2p mix protocol is production-ready and support with the publishing of a paper and blog posts Ensure decentralized MLS is production-ready and support with the publishing of a paper and blog posts Begin explorations of additional research topics Release Zerokit v0.7 and future versions","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-4","p":1},{"i":34,"t":"The P2P Service Unit specializes in peer-to-peer technologies and develops nim-libp2p, improves the libp2p GossipSub protocol, and assists IFT portfolio projects with the integration of P2P network layers.","s":"P2P","u":"/rlog/2024-recap","h":"#p2p","p":1},{"i":36,"t":"Analysis and work on libp2p GossipSub improvements Published: Libp2p GossipSub IDONTWANT Message Performance Impact PR to libp2p specifications about specific lib2p GossipSub improvements we researched and tested https://github.com/libp2p/specs/pull/654","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-5","p":1},{"i":38,"t":"Add new features to nim-libp2p: QUIC transport, web transport Update specifications for libp2p GossipSub, aiming to significantly improve its performance","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-5","p":1},{"i":40,"t":"The DST Service Unit’s primary objective is to assist IFT portfolio projects in understanding the scaling behavior of their nodes within larger networks. By conducting thorough regression testing, the DST unit helps ensure the reliability and stability of projects.","s":"Distributed Systems Testing (DST)","u":"/rlog/2024-recap","h":"#distributed-systems-testing-dst","p":1},{"i":42,"t":"DST compute resources transitioned from a hosted environment to a dedicated Vac Lab, enabling better customization of resources and adding significantly more compute power – enabled much higher and more stable simulations (several hundred nodes to several thousand) and enhanced environmental control. Maintained monthly regression simulations for both Waku and Nim-libp2p, helping us to detect several issues and ensure that future versions do not introduce new ones. Successfully simulated and obtained results for all Waku protocols, relaying feedback to the team.","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-6","p":1},{"i":44,"t":"More testing and simulations for Codex and Nomos Develop useful tools for all IFT portfolio projects – e.g. a Log Parser tool and data dashboard","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-6","p":1},{"i":46,"t":"Several IFT portfolio projects use the Nim ecosystem for its efficiency. The Nim Service Unit is responsible for the development and maintenance of Nim tooling.","s":"Nim","u":"/rlog/2024-recap","h":"#nim","p":1},{"i":48,"t":"Released Nim-libp2p (v1.7.1, v1.7.0, v1.6.0, v1.5.0, v1.4.0, v1.3.0, v1.2.0) Introduced SAT solver to the Nimble package manager that significantly improves dependency resolution Nim VSCode Extension Stabilized Nim Language Server","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-7","p":1},{"i":50,"t":"Vac's Smart Contracts Service Unit ensures the smart contracts deployed across the various IFT portfolio projects are secure, robust, and aligned with project requirements.","s":"Smart Contracts (SC)","u":"/rlog/2024-recap","h":"#smart-contracts-sc","p":1},{"i":52,"t":"Deployed the SNT staking protocol testnet following Status's governance vote to develop SNT staking and Status Network Wrote specifications for Codex's architectural components and Status's staking contracts Delivered several learn-up sessions on a variety of topics for IFT contributors, including: Stealth addresses Tokenized vaults Rental NFTs Merkle trees Account abstraction EVM deep dive","s":"Highlights","u":"/rlog/2024-recap","h":"#highlights-8","p":1},{"i":54,"t":"Deploy the SNT staking protocol on the Status Network testnet Encourage community security audits via contests Provide smart contract consultation services for IFT portfolio products Engage in more learn-up sessions to promote org-wide knowledge sharing.","s":"Looking forward","u":"/rlog/2024-recap","h":"#looking-forward-7","p":1},{"i":56,"t":"This year has seen Vac involved with many research, development, and testing undertakings in support of IFT portfolio projects. The digital public goods that emerge from our efforts not only support the organization itself but are open and free to use by any project that would benefit. As we move into 2025, we aim to nurture a stronger RFC culture across the IFT to encourage greater collaboration and knowledge sharing among portfolio projects. Our goal is to serve as an internal conduit of expertise within the organization, supported by a strong RFC culture, maintaining a repository of internal knowledge creation, and identifying and facilitating IFT project synergies. Such an approach should lead to greater efficiencies across the organization. We also aim to establish a diverse research community around Vac, and our efforts in this regard are already underway. In the final quarter of 2024, Vac stepped up its collaboration with the libp2p community and made a concerted effort to engage the community on the Vac forum. In 2025, we aim to continue working closely with those communities to which we already have ties, such as the libp2p, Ethereum, and Nim ecosystems. We look forward to continuing our journey with you! Follow Vac on X, join us in the Vac Discord, or take part in the discussions on the Vac forum to stay up to date with our research and development progress.","s":"Heading into 2025","u":"/rlog/2024-recap","h":"#heading-into-2025","p":1},{"i":59,"t":"This post introduces de-MLS, a decentralized variant of Message Layer Security (MLS) that reimagines group messaging by replacing centralized delivery services with peer-to-peer protocols while retaining strong guarantees such as forward secrecy (FS) and post-compromise security (PCS).","s":"Decentralized Message Layer Security (De-MLS) with Waku","u":"/rlog/de-mls-with-waku","h":"","p":58},{"i":61,"t":"Secure Group Messaging (SGM) is resource-intensive when aiming for robust security features like forward secrecy (FS) and post-compromise security (PCS). One straightforward approach to SGM is a pairwise group chat, where each pair of group members establishes a unique encryption key using Diffie-Hellman. While this method ensures security, it falls short in terms of practicality: High storage requirements: Each participant must store encryption keys for every other participant. Inefficient encryption: Each message must be encrypted separately for every participant, leading to significant computational overhead. Inefficient message storage and delivery: Each separately encrypted message must then be sent over the wire, whatever this wire might be. Or stored in database. Cumbersome group management: Adding or removing users and refreshing keys becomes increasingly inefficient as the group grows. One scalable for Secure Group Messaging (SGM) is Message Layer Security (MLS), as standardized in RFC 9420. Leveraging TreeKEM, MLS organizes group members in a cryptographic tree structure, where each participant is responsible for maintaining specific parts of the tree. While MLS offers scalability and strong security guarantees, its reliance on server-based delivery services poses limitations for fully decentralized environments. In this post, we present the implementation details of the first version of Decentralized MLS (de-MLS) which is an SGM protocol. De-MLS can serve groups that cannot rely on central servers, such as journalists and activists seeking secure communication. It is also well suited for DAOs, where Ethereum-based authentication can restrict access to members holding a minimum ETH balance, and for NGOs or research consortia that prefer not to host their own servers while still requiring end-to-end encrypted group messaging. Decentralized MLS (de-MLS) satisfies the following features: Decentralized Scalable End-to-end encrypted (E2EE) FS and PCS provided Ethereum authenticated","s":"Introduction","u":"/rlog/de-mls-with-waku","h":"#introduction","p":58},{"i":64,"t":"The Message Layer Security (MLS) protocol offers scalable and secure group messaging protocol by organizing participants into a cryptographic tree structure, enabling efficient operations like adding or removing members with logarithmic time complexity relative to the group size. MLS provides strong security guarantees, including FS and PCS. MLS assumes that two services are provided: An Authentication Service (AS): It enables group members to authenticate the credentials presented by other group members. A Delivery Service (DS) that routes MLS messages among the participants in the protocol in the correct order and manage the keyPackage of the users where the keyPackage is the objects that provide some public information about a user. Despite its scalability, MLS has a notable limitation: it is inherently designed for server-based federated architectures for delivery service (DS), even when the servers themselves don't need to be trusted. To achieve a decentralized protocol, the functionality of DS must be reimagined to eliminate reliance on a central server while preserving the protocol's security properties. Thus, we proposed decentralized MLS (de-MLS), leveraging Waku nodes as peer-to-peer communication protocols to eliminate reliance on centralized servers. Lastly, MLS operates on an epoch-based model, where group state changes (e.g., adding/removing users or key refreshes) occur between epochs that are always required to be conducted by a single entity. For example, if a user is removed in epoch E, the rest of the group members generate a new key in epoch E + 1 by passing the new entropy. The removed user cannot decrypt messages sent after epoch E + 1.","s":"MLS","u":"/rlog/de-mls-with-waku","h":"#mls","p":58},{"i":66,"t":"Waku is a decentralized messaging protocol designed for secure and efficient communication in peer-to-peer networks. It operates as a broadcast-based routing layer where content topics can be used to tag and filter messages. Users join channels by subscribing to specific content topics, which determine the scope and type of messages exchanged. This enables flexible and efficient communication patterns in a decentralized environment.","s":"Waku","u":"/rlog/de-mls-with-waku","h":"#waku","p":58},{"i":68,"t":"Decentralized MLS (de-MLS) is a peer-to-peer secure group messaging protocol that can work with any delivery service (DS) meeting a minimal set of requirements. In this post, we highlight its integration with Waku as the messaging protocol, while emphasizing that de-MLS itself remains agnostic to the underlying DS. Further technical details can be found in the de-MLS RFC. Decentralization is achieved not only at the delivery service (DS) level but also within the authentication service (AS). Multiple special nodes named Steward in the group serve as authorized identities to authenticate users before they join or are removed from the group transparently. de-MLS provides two different user management configurations, both utilizing the Waku protocol for DS: Single Steward: A single authorized identity (Steward) manages the group, including removing or adding users with agreement among users by a voting-based consensus. Multi-Steward: Multiple Stewards have equal authority to add or remove users. A consensus mechanism ensures consistency by resolving concurrent changes within the same epoch and preventing possible conflicts. In each epoch, all modifications are managed exclusively by a single Steward. Note: We chose the term Steward to reflect the role of transparently coordinating and organizing passengers at stations, much like Stewards do in transit systems. In multi-Steward settings, de-MLS requires a consensus among Stewards that have equal rights in the group since changes in an epoch in MLS are required to be conducted by a single identity, that is the Steward. For the consensus integration, ongoing research explores two promising approaches: On-chain consensus mechanisms: Outsourcing consensus to a smart contract solution for transparent and immutable agreement. Off-chain consensus mechanisms: Utilizing off-chain consensus protocols to design efficient, decentralized protocols.","s":"de-MLS","u":"/rlog/de-mls-with-waku","h":"#de-mls","p":58},{"i":70,"t":"Waku integration is a crucial step in the construction of de-MLS, aiming to replace traditional client-server communication with decentralized messaging. The specifics of Waku integration will be detailed in a separate RFC; for now, our main priority is the de-MLS RFC. The main challenge in this transition is transforming the centralized Delivery Service (DS) into a decentralized equivalent, which performs two essential functions: Message Delivery and Ordering: The DS is responsible not only for delivering messages to the correct recipients, but also for preserving the correct order of these messages, which is critical for the consistency of group state. Key Package Management: The DS manages key packages, which are essential for adding members securely to a group. To maintain a truly decentralized architecture, key packages cannot be stored in a centralized location. Initially, we considered using a smart contract (SC) as a decentralized substitute for server-side key package storage. However, this approach proved impractical. Blockchains are immutable by design—once data is written, it cannot be fully removed. This contradicts a core requirement of MLS: each key package must be used exactly once and then deleted, to prevent replay or reuse attacks. Instead, our solution is to require users to actively provide their key packages upon request, allowing validation at the moment of use without persistent storage. While this approach may lose some benefits of asynchronicity, we plan to address this in the future by introducing store nodes that can temporarily hold key packages. This ensures both compliance with MLS's security model and alignment with decentralized system principles.","s":"Waku Integration","u":"/rlog/de-mls-with-waku","h":"#waku-integration","p":58},{"i":72,"t":"The flow section explains the processes that when a user wants to join a group in both Steward and users side also their interactions. The flow of de-MLS is as follows:","s":"Flow","u":"/rlog/de-mls-with-waku","h":"#flow","p":58},{"i":74,"t":"The welcome topic is a topic created and monitored by the Steward for a specific secure messaging group, allowing any Waku node to subscribe permissionlessly. Being in the welcome topic does not imply group membership, it acts as a waiting room where users can send their key material, which the Steward listens for and processes before granting access to the secure group.","s":"1. Steward joins the welcome topic","u":"/rlog/de-mls-with-waku","h":"#1-steward-joins-the-welcome-topic","p":58},{"i":76,"t":"Steward initalizes a group with parameters such as cipher suite and group ID.","s":"2. Group initialization","u":"/rlog/de-mls-with-waku","h":"#2-group-initialization","p":58},{"i":78,"t":"Steward creates group announcement (GA) periodically to the welcome channel that the users can find the who the Steward is. This will be important for the next step.","s":"3. Emitting Group Anouncement (GA) by Steward","u":"/rlog/de-mls-with-waku","h":"#3-emitting-group-anouncement-ga-by-steward","p":58},{"i":80,"t":"As first, the users who wants to be part of the decentralized MLS should subscribe the welcome channel. Then user can find the group name and also corresponding GA message from Steward. This GA message helps the user to create a valid keyPackages which define in section 10 in RFC9420 for the group.","s":"4. User joins the welcome topic","u":"/rlog/de-mls-with-waku","h":"#4-user-joins-the-welcome-topic","p":58},{"i":82,"t":"User creates the keyPackage and encrypt by public key of the Steward then send it to the Steward. Since the message is encrypted, stay secure though the welcome (permissionless) topic.","s":"5. User creates its key package","u":"/rlog/de-mls-with-waku","h":"#5-user-creates-its-key-package","p":58},{"i":84,"t":"Steward receives the user's keyPackage and decrypt it. After decrypted, Steward also verifies the validity of the keyPackage by signature verification. If the keyPackage is not valid, the Steward just drops the message, otherwise it moves to the next step which is proposal creation.","s":"6. Steward receives the User's key package","u":"/rlog/de-mls-with-waku","h":"#6-steward-receives-the-users-key-package","p":58},{"i":86,"t":"Voting proposals are special MLS application messages that may come from any participant, including the Steward. In this context, any member can create a proposal corresponding to the user’s keyPackage. In regular MLS, proposals are automatically converted into commit messages, which can change the structure of the tree. However, in de-MLS, since the process is decentralized, proposals must be voted on before being converted into a commitment.","s":"7. Creation of Voting proposals","u":"/rlog/de-mls-with-waku","h":"#7-creation-of-voting-proposals","p":58},{"i":88,"t":"Voting applies decentralization by protecting small groups can control. Therefore, proposals must be voted on before committing. The consensus mechanism should be a lightweight consensus that cannot be a bottleneck for treeKEM scalability. Basically, the consensus returns the binary result for a given proposal. If voting result is NO, the proposal is dropped; otherwise, the Steward transforms it into an MLS proposal. MLS proposal message is a distinct type of MLS application message, where the Steward attaches the voting result instead of directly releasing a commit message.","s":"8. Voting for proposal","u":"/rlog/de-mls-with-waku","h":"#8-voting-for-proposal","p":58},{"i":90,"t":"Commit messages are the messages that start new epochs. They include key and tree material that existing members can use to generate the new state of the tree. After Steward gets the YES from consensus, Steward creates commit messages that injects new entropy for the existing group members.","s":"9. Creating commit message","u":"/rlog/de-mls-with-waku","h":"#9-creating-commit-message","p":58},{"i":92,"t":"After Steward creates and then sends two messages: Commit message informs existing group member to update their key to align with the new member’s key for the upcoming epoch. The welcome message informs the newly joined user to generate a group key that matches the key existing members will use in the upcoming epoch. Although existing users had different group keys in the previous epoch and the new user had none, the Steward message ensures that both existing and new users converge on the same group key in the next epoch.","s":"10. Sending messages","u":"/rlog/de-mls-with-waku","h":"#10-sending-messages","p":58},{"i":94,"t":"User can generate the next epoch group key by using the welcome message as well as existing users extract the same groupKey by using commit messages. The commit message helps existing members generate the next group key Gk+1, while the welcome message helps the newly joining user generate the same Gk+1. This provides two important security properties: Forward Secrecy (FS): The new user cannot read previous messages since they were encrypted with the old key Gk Post-Compromise Security (PCS): If a user is removed from the group, they cannot read future messages since those messages will be encrypted with the new key Gk+1","s":"11. Applying welcome message","u":"/rlog/de-mls-with-waku","h":"#11-applying-welcome-message","p":58},{"i":96,"t":"This section presents the performance evaluation of de-MLS. One of the key advantages of the MLS protocol is its efficiency, as it eliminates the need for pairwise message exchanges between all participants. Instead, the decentralized DS enables the addition of new participants by sending only two messages to the group: a commit message and a welcome message. However, despite this advantage, the protocol does have certain bottlenecks, which are as follows: Firstly, the Steward must receive the key packages from each member wishing to join the group. This process requires sequential message exchanges and involves computationally intensive tasks such as encryption, decryption, and digital signature verification. Even when multiple users are added to the group simultaneously, the process is essentially sequential. The tree structure is updated one user at a time, followed by sending the final commit message to the existing group members and a single welcome message to the new members. Secondly adding a member to a group requires rebuilding the tree and computing new keys. The following measurements were made as follows: The time required for the entire sequence of receiving a user key package is presented here. This includes generating the Steward key, creating messages with signatures and encryption, and processing these messages. Share Key Package - 1.8395 ms Note that these measurements do not account for the time taken to forward messages. The time required for creating the commit and welcome message from a ready-made package bunches is shown in this table. Group Size (by users) Time 10 1.8662 ms 100 14.124 ms 500 121.85 ms 1000 412.39 ms 5000 ~ 15-20 s 10000 ~ 1-1.5 min The tests were conducted on the following configuration: Apple M3 Pro @ 4.05GHz and 12-Core CPU/18-Core GPU. Here, the network latency and the time taken by users to apply the received commits are also excluded. These aspects are planned to be measured and evaluated in future work.","s":"Benchmark","u":"/rlog/de-mls-with-waku","h":"#benchmark","p":58},{"i":98,"t":"Since de-MLS replace the servers by P2P, we could lose some good features of servers based MLS. In this section we present the potential drawbacks and possible countermeasures of de-MLS. Offline users: keyPackages are provided by the users directly without any storing, this is required each user must be online for joining to a group. We can consider to use Waku sync nodes that are nodes has storing ability for a temporary storing of keyPackages. DoS attack to Steward: Steward is known in welcome message from periodic group announcement message so Steward can be targeted for DoS attack. As always we consider to use Rate-Limiting Nullifier (RLN) with Waku to protect network from spam. Message loss or delay : Because of P2P and consensus settings, message can be lost or delayed., We can integrate reliability mechanisms to Waku such as scalable data sync (SDS) Consensus mechanism requires to provide liveness property against offline nodes, for example, it may provides default YES or NO options for a silent users who do not vote. Enchanced authentication Ethereum authentication could be inefficient. We can configure the authentication mechanism for example asking minimum balance or etc.","s":"Potential drawbacks and countermeasures","u":"/rlog/de-mls-with-waku","h":"#potential-drawbacks-and-countermeasures","p":58},{"i":100,"t":"To summarize, the approach to solving decentralized DS tasks with Waku can be outlined as shown in the comparison table: Feature MLS de-MLS Message Distribution Messages are sent from the server to clients Messages are sent by publishing/subscribing to pub-sub topics Commit Message Handling Relies on a server Relies on a consensus and transparent Steward Key Package Management Key packages are stored and distributed by the server Key packages are provided by the users themselves","s":"Conclusion","u":"/rlog/de-mls-with-waku","h":"#conclusion","p":58},{"i":102,"t":"In the next iterations, the implementations are planned as following: Dual-Consensus Multi-Steward Support: One consensus mechanism selects an Steward from all users, while a second governs group decisions among the elected Stewards Consensus mechanism for handling concurrent changes within the same epoch Key rotation support Benchmarking for the multi-Steward configuration including the network time","s":"Future Work","u":"/rlog/de-mls-with-waku","h":"#future-work","p":58},{"i":104,"t":"[1] RFC 9420: The Messaging Layer Security (MLS) Protocol. Retrieved from https://datatracker.ietf.org/doc/rfc9420/ [2] OpenMLS. Retrived from https://github.com/openmls/openmls [3] Waku. Retrived from https://waku.org/ [4] de-MLS. Retrived from https://github.com/vacp2p/de-mls/","s":"References","u":"/rlog/de-mls-with-waku","h":"#references","p":58},{"i":107,"t":"Zerokit is a toolkit providing powerful zero-knowledge utilities, including a means to answer the question \"How do you prevent spam when every message is anonymous?\". Its use of the Merkle hash tree, combined Poseidon hasher are keys to the answer we seek here, and with other questions that ask the improbable. These technologies, however, can take a heavy toll on resources if not used correctly. What follows is a window into the efforts made to squeeze out optimizations, and culling of redundant resource use. A story of cripplingly slow performance meets engineering talent, we arrive at a place where Zerokit comes through, fast and efficient, ready to face the world.","s":"Zerokit optimizations: A performance journey","u":"/rlog/2025-zerokit-perf","h":"","p":106},{"i":109,"t":"Our friends over at Waku are particularly enthusiastic about anonymous spam prevention technologies. They have been using the Rate Limiting Nullifier (RLN) tooling that Zerokit provides to enforce a message-rate policy among users—a crucial feature unless we want a community bombarded with \"totally legit, not scams\" messages on repeat. However, as is often the case with new technology, some problematic delays began to surface. Node recalculations, a common operation, were taking tens of seconds at the scales being tested and deployed—even exceeding 40 seconds at times. These delays accumulate, leading to total delays on the order of three hours under certain conditions. Naturally, we couldn't just let this sit. While we've touched on the issue of spam prevention, it's important to recognize that this technology is foundational that challenges conventional wisdom on how things must be done. Does the idea of \"smart contracts without gas\" catch your attention? Don't hold your breath just yet: the really interesting applications of this tech will be dead in the water, unless we can meet the challenge put to us.","s":"Background","u":"/rlog/2025-zerokit-perf","h":"#background","p":106},{"i":111,"t":"The plan of attack that the team put together was twofold: get rid of redundant operations and data taking up precious resources, and make the remaining operations go Blazingly Fast™. Introducing the star of the show for part 1: The main point of having this tree is to generate proofs so that peers can verify the claims being made. That doesn’t require the whole Merkle tree, just a single path, from leaf to root. The engineering work took us in a direction where these paths were the primary context in which ZK proofs operated, relegating the tree itself to an off-network reference. This reduced the burden imposed on the network significantly. Updating the data on the tree has similarly reduced, with the exception being that the siblings of each node were retained. This is called the stateless approach. Well, stateless in the context of proof generation and verification. This is the critical context when it comes to performance, and the stateless approach does a great job, but these proofs have to come from somewhere. Each participant still needs to maintain the Merkle tree in their local environment. Without this tree, one cannot generate proofs or verify the proofs provided to them. Fortunately, one does not need to track the entire tree, but can be limited to a subset of the tree needed. With millions of participants on-chain, this can make the difference needed to make Zerokit empowered technologies accessible to those running raspberry Pis. Combine this with the fact that the heavy lifting operations of proof gen/verification being modular and separate, each participant can optimise to run things according to the strengths and requirements of their native hardware, easing the way to allow each participants to run their tree implementation at the speed of mach-ludicrous. Fortunately, the core of our already existing implementation was sane and well put together. Double-lucky for us, the talents of newly minted VAC/ACZ team members Sylvain and Vinh were readily available. Sylvain, with a solid background in the Rust programming language, having already graduated from the most challenging parts of its infamous learning curve. He quickly got to work zeroing in on some subtle performance pathologies. Something as simple as using a mutable iterator to change values directly. Clever use of references to avoid copying data, and other memory optimization techniques that can be hidden to those that cannot “see the matrix” when working in Rust lead to very promising bench-marking results. Vinh, having recently graduated from his CS studies, was presented with the challenge of parrelising computations. For those not familiar with Rust, this might seem unreasonable, but thanks to the rayon crate, and Rusts promise of \"fearless concurrency\" afforded by its type and ownership system, this kind of refactor becomes surprisingly easy, even for a talented individual at the start of their career. Of particular note: These parallelisations have been made available to the browser. Browser threads are relatively now, and by diving into this bleeding-edge technology, and making use of libraries that are still in early development stages, Blazingly Fast™ is now available within the browser. With all that in the bag, all these performance gains are gift-wrapped in the use of browser-native WASM runtimes. Well done, everyone!","s":"The Challenge","u":"/rlog/2025-zerokit-perf","h":"#the-challenge","p":106},{"i":113,"t":"No performance project is complete without high quality benchmark data. Writing a quick benchmark for tracking improvements through development is one thing, but having a system of telemetry that allows you to credibly assert claims of superior performance is what completes the project. With such credible claims in hand, these efforts can bring about significant impact on the field at large. The key word being credible. Credibility cannot depend on “trust me bro” (obviously). The truth of these claims must come out of the directed efforts of a multitude of thought-disciplines. The engineer must have a solid model to understand the nature of the system. The statistician sets the quality standards of the data. The Scientist must diligently put relevant hypothesis to the test. The advocate must see that the reports made reach out to where it makes the most impact, the list goes on. Much of this is out of scope for this article, and so I will treat you with a link. Here’s your chance to see a hardcore OS engineer at the top of their chosen field speak on the subject of their passion. All this is to say we are not the only team implementing Merkle tree tech, which also includes the Poseidon hash function it needs. In order to be a premier research destination, key aspect of why VAC exists, the fruits of our labor is just the beginning. We must prove the merit of our efforts through comparative benchmarks that satisfies the skeptics and decision makers. Comparative benchmarks are among the most high-stakes element of performance critical projects. Get it right, and quality research output can become industry standard technology. Get it wrong, and be ready to lose the trust the field has in you as your precious R&D fades into obscurity. For the time being, our comparative benchmarks have been used internally to inform decision-makers. As benchmarks become standardised, independently verified and executed, this initial effort may be the first of many steps to a community-wide ecosystem. A thunderdome of benchmarks, leaving us with a single champion that cannot be denied, but which technology will claim this mantle? May the bits be ever in your favor...","s":"The importance of benchmarks","u":"/rlog/2025-zerokit-perf","h":"#the-importance-of-benchmarks","p":106},{"i":115,"t":"Rust, much like Nim, offers unadulterated, fine-grained, and direct control over performance, but with Rust, this control is even more immediate. With its sophisticated ownership model, powerful type system, and comprehensive tooling, Rust has earned an unrivaled reputation for enabling \"fearless concurrency,\" ease of refactoring, and providing tooling that effectively \"pair programs with you\" to help avoid common pitfalls, includeing those of the performance veriety. The criterion crate is considered the go-to library for micro-benchmarking within the Rust ecosystem, and is generally regarded as an invaluable tool for obtaining high-quality telemetry. Through its ergonomic idioms and well-thought-out API, writing high-quality benchmarks becomes straightforward once you become familiar with its features. Criterion helps avoid common traps such as inappropriate compiler optimizations, improper performance sampling, and failing to prune telemetry overhead. As is typical for the Rust ecosystem, the documentation is thorough, leaving little to be desired, and the examples are extensive, making the initial learning process a pleasant experience. Most importantly, it automatically generates tables and graphs from this data, making the crucial task of analysis straightforward and accessible. At this point, we are ready to appreciate the results of our efforts.","s":"Benchmarking with Rust's criterion crate","u":"/rlog/2025-zerokit-perf","h":"#benchmarking-with-rusts-criterion-crate","p":106},{"i":117,"t":"When it comes to Merkle trees, we have two elements to consider: The tree itself, and the hashing function that is plugged into it. In the benchmarks we put together for the benefit of internal processes, we put our implementation up against a corresponding FOSS implementation. Scenarios were developed to isolate key performance telemetry, obtain a statistically usable sampling, with the resulting data rendered into a human readable form that can be read with a reasonable degree of confidence: enjoy! The brief summary: It appears that our in house implementation consistently outperforms others, and we’ve decided to continue committing to the R&D of our in-house implementations. Congratulations to the Zerokit team for this accomplishment. Despite the promising results, these “micro-benchmarks” form just some of the many pieces of the whole system performance when it comes to product needs. How the system performs as a whole is all that matters. This is a promising on it’s own, but watching the performance benefits being realized in the wild is the true goal. Which brings us back to what started all this: Waku came to us with concerns about performance issues within Zerokit limiting the scope and scale in which it can be used. The engineering talent brought to bear on this issue has successfully achieved the performance goals needed, and the results of these effort have demonstrated there is merit in continuing our commitment to this project.","s":"Promising results","u":"/rlog/2025-zerokit-perf","h":"#promising-results","p":106},{"i":119,"t":"We’ve covered a story that starts with crippling performance bottlenecks in Waku, and ends on this high-note: The problematic performance scaling issues are no more, and in the process of resolving this critical pain-point, we have established internal benchmarks that allow us to confidently state that what we are doing, we are doing well. These accomplishments come down to a solid team effort. The open communication coming in from Waku, the talented engineers working together to bring their skills and contributions to bear, the community developed tools and prior works that allowed it all to happen, and those working quietly in the background providing the leadership, resources, and coordination needed to bring this all together. Two VAC/ACZ engineers in particular call for specific mention: Ekaterina for her role in taking lead in the R&D of the Zerokit ecosystem, and Sylvain for his efforts in squeezing out some impressive optimizations. Vinh for unleashing the power of multiple threads, not only for native, but for when running in the browser as well. Perhaps you want to get involved! Maybe you have some ideas about what the community needs for standard benchmarks. Would you like to see another implementation added to the thunderdome? Raise an issue, or join us on our forum. We look forward to seeing your voice added. This is just one story, coming out of one relatively small project from VAC research. The two driving directives of the team is to be a conduit of expertise within IFT, and to be a premier research destination within the domains we work in. You might be independent of IFT with an interest in what we do, an IFT core contributor, or anything in between: our services are at your disposal. Join us on discord to start the conversation, email one of our team members, or maybe you might hear a knock on your door, should something in your field of work catch our interest.","s":"Conclusion","u":"/rlog/2025-zerokit-perf","h":"#conclusion","p":106},{"i":121,"t":"What is privacy-protecting infrastructure? Why do we need it and how we can build it? We'll look at Waku, the communication layer for Web3. We'll see how it uses ZKPs to incentivize and protect the Waku network. We'll also look at Zerokit, a library that makes it easier to use ZKPs in different environments. After reading this, I hope you'll better understand the importance of privacy-protecting infrastructure and how we can build it. This write-up is based on a talk given at DevCon 6 in Bogota, a video can be found here","s":"Building Privacy-Protecting Infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","h":"","p":120},{"i":123,"t":"In this write-up, we are going to talk about building privacy-protecting infrastructure. What is it, why do we need it and how can we build it? We'll look at Waku, the communication layer for Web3. We'll look at how we are using Zero Knowledge (ZK) technology to incentivize and protect the Waku network. We'll also look at Zerokit, a library we are writing to make ZKP easier to use in different environments. At the end of this write-up, I hope you'll come away with an understanding of the importance of privacy-protecting infrastructure and how we can build it.","s":"Intro","u":"/rlog/building-privacy-protecting-infrastructure","h":"#intro","p":120},{"i":125,"t":"First, briefly about Vac. We build public good protocols for the decentralized web, with a focus on privacy and communication. We do applied research based on which we build protocols, libraries and publications. We are also the custodians of protocols that reflect a set of principles. It has its origins in the Status app and trying to improve the underlying protocols and infrastructure. We build Waku, among other things.","s":"About","u":"/rlog/building-privacy-protecting-infrastructure","h":"#about","p":120},{"i":127,"t":"Privacy is the power to selectively reveal yourself. It is a requirement for freedom and self-determination. Just like you need decentralization in order to get censorship-resistance, you need privacy to enable freedom of expression. To build applications that are decentralized and privacy-protecting, you need the base layer, the infrastructure itself, to have those properties. We see this a lot. It is easier to make trade-offs at the application layer than doing them at the base layer. You can build custodial solutions on top of a decentralized and non-custodial network where participants control their own keys, but you can't do the opposite. If you think about it, buildings can be seen as a form of privacy-protecting infrastructure. It is completely normal and obvious in many ways, but when it comes to the digital realm our mental models and way of speaking about it hasn't caught up yet for most people. I'm not going too much more into the need for privacy or what happens when you don't have it, but suffice to say it is an important property for any open society. When we have conversations, true peer-to-peer offline conversations, we can talk privately. If we use cash to buy things we can do commerce privately. On the Internet, great as it is, there are a lot of forces that makes this natural state of things not the default. Big Tech has turned users into a commodity, a product, and monetized user's attention for advertising. To optimize for your attention they need to surveil your habits and activities, and hence breach your privacy. As opposed to more old-fashioned models, where someone is buying a useful service from a company and the incentives are more aligned. We need to build credibly neutral infrastructure that protects your privacy at the base layer, in order to truly enable applications that are censorship-resistant and encourage meaningful freedom of expression.","s":"Why build privacy-protecting infrastructure?","u":"/rlog/building-privacy-protecting-infrastructure","h":"#why-build-privacy-protecting-infrastructure","p":120},{"i":129,"t":"Infrastructure is what lies underneath. Many ways of looking at this but I'll keep it simple as per the original Web3 vision. You had Ethereum for compute/consensus, Swarm for storage, and Whisper for messaging. Waku has taken over the mantle from Whisper and is a lot more usable today than Whisper ever was, for many reasons. On the privacy-front, we see how Ethereum is struggling. It is a big UX problem, especially when you try to add privacy back \"on top\". It takes a lot of effort and it is easier to censor. We see this with recent action around Tornado Cash. Compare this with something like Zcash or Monero, where privacy is there by default. There are also problems when it comes to the p2p networking side of things, for example with Ethereum validator privacy and hostile actors and jurisdictions. If someone can easily find out where a certain validator is physically located, that's a problem in many parts of the world. Being able to have stronger privacy-protection guarantees would be very useful for high-value targets. This doesn't begin to touch on the so called \"dapps\" that make a lot of sacrifices in how they function, from the way domains work, to how websites are hosted and the reliance on centralized services for communication. We see this time and time again, where centralized, single points of failure systems work for a while, but then eventually fail. In many cases an individual user might not care enough though, and for platforms the lure to take shortcuts is strong. That is why it is important to be principled, but also pragmatic in terms of the trade-offs that you allow on top. We'll touch more on this in the design goals around modularity that Waku has.","s":"Web3 infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","h":"#web3-infrastructure","p":120},{"i":131,"t":"ZKPs are a wonderful new tool. Just like smart contracts enables programmable money, ZKPs allow us to express fundamentally new things. In line with the great tradition of trust-minimization, we can prove statement while revealing the absolute minimum information necessary. This fits the definition of privacy, the power to selectively reveal yourself, perfectly. I'm sure I don't need to tell anyone reading this but this is truly revolutionary. The technology is advancing extremely fast and often it is our imagination that is the limit.","s":"ZK for privacy-protecting infrastructure","u":"/rlog/building-privacy-protecting-infrastructure","h":"#zk-for-privacy-protecting-infrastructure","p":120},{"i":133,"t":"What is Waku? It is a set of modular protocols for p2p communication. It has a focus on privacy, security and being able to run anywhere. It is the spiritual success to Whisper. By modular we mean that you can pick and choose protocols and how you use them depending on constraints and trade-offs. For example, bandwidth usage vs privacy. It is designed to work in resource restricted environments, such as mobile phones and in web browsers. It is important that infrastructure meets users where they are and supports their real-world use cases. Just like you don't need your own army and a castle to have your own private bathroom, you shouldn't need to have a powerful always-on node to get reasonable privacy and censorship-resistance. We might call this self-sovereignty.","s":"Waku","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku","p":120},{"i":135,"t":"One way of looking at Waku is as an open service network. There are nodes with varying degrees of capabilities and requirements. For example when it comes to bandwidth usage, storage, uptime, privacy requirements, latency requirements, and connectivity restrictions. We have a concept of adaptive nodes that can run a variety of protocols. A node operator can choose which protocols they want to run. Naturally, there'll be some nodes that do more consumption and other nodes that do more provisioning. This gives rise to the idea of a service network, where services are provided for and consumed.","s":"Waku - adaptive nodes","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku---adaptive-nodes","p":120},{"i":137,"t":"There are many protocols that interact. Waku Relay protocol is based on libp2p GossipSub for p2p messaging. We have filter for bandwidth-restricted nodes to only receive subset of messages. Lightpush for nodes with short connection windows to push messages into network. Store for nodes that want to retrieve historical messages. On the payload layer, we provide support for Noise handshakes/key-exchanges. This means that as a developers, you can get end-to-end encryption and expected guarantees out of the box. We have support for setting up a secure channel from scratch, and all of this paves the way for providing Signal's Double Ratchet at the protocol level much easier. We also have experimental support for multi-device usage. Similar features have existed in for example the Status app for a while, but with this we make it easier for any platform using Waku to use it. There are other protocols too, related to peer discovery, topic usage, etc. See specs for more details.","s":"Waku - protocol interactions","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku---protocol-interactions","p":120},{"i":139,"t":"For the Waku network, there are a few problems. For example, when it comes to network spam and incentivizing service nodes. We want to address these while keeping privacy-guarantees of the base layer. I'm going to go into both of these. The spam problem arises on the gossip layer when anyone can overwhelm the network with messages. The service incentivization is a problem when nodes don't directly benefit from the provisioning of a certain service. This can happen if they are not using the protocol directly themselves as part of normal operation, or if they aren't socially inclined to provide a certain service. This depends a lot on how an individual platform decides to use the network.","s":"Waku - Network","u":"/rlog/building-privacy-protecting-infrastructure","h":"#waku---network","p":120},{"i":141,"t":"Since the p2p relay network is open to anyone, there is a problem with spam. If we look at existing solutions for dealing with spam in traditional messaging systems, a lot of entities like Google, Facebook, Twitter, Telegram, Discord use phone number verification. While this is largely sybil-resistant, it is centralized and not private at all. Historically, Whisper used PoW which isn't good for heterogenerous networks. Peer scoring is open to sybil attacks and doesn't directly address spam protection in an anonymous p2p network. The key idea here is to use RLN for private economic spam protection using zkSNARKs. I'm not going to go into too much detail of RLN here. If you are interested, I gave a talk in Amsterdam at Devconnect about this. We have some write-ups on RLN here by Sanaz who has been pushing a lot of this from our side. There's also another talk at Devcon by Tyler going into RLN in more detail. Finally, here's the RLN spec. I'll briefly go over what it is, the interface and circuit and then talk about how it is used in Waku.","s":"Dealing with network spam and RLN Relay","u":"/rlog/building-privacy-protecting-infrastructure","h":"#dealing-with-network-spam-and-rln-relay","p":120},{"i":143,"t":"RLN stands for Rate Limiting Nullifier. It is an anonyomous rate limiting mechanism based on zkSNARKs. By rate limiting we mean you can only send N messages in a given period. By anonymity we mean that you can't link message to a publisher. We can think of it as a voting booth, where you are only allowed to vote once every election. It can be used for spam protection in p2p messaging systems, and also rate limiting in general, such as for a decentralized captcha. There are three parts to it. You register somewhere, then you can signal and finally there's a verification/slashing phase. You put some capital at risk, either economic or social, and if you double signal you get slashed.","s":"RLN - Overview and Flow","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln---overview-and-flow","p":120},{"i":145,"t":"Here's what the private and public inputs to the circuit look like. The identity secret is generated locally, and we create an identity commitment that is inserted into a Merkle tree. We then use Merkle proofs to prove membership. Registered member can only signal once for a given epoch or external nullifier, for example every ten seconds in Unix time. RLN identifer is for a specific RLN app. We also see what the circuit output looks like. This is calculated locally. y is a share of the secret equation, and the (internal) nullifier acts as a unique fingerprint for a given app/user/epoch combination. How do we calculate y and the internal nullifier? // Private input signal input identity_secret; signal input path_elements[n_levels][1]; signal input identity_path_index[n_levels]; // Public input signal input x; // signal_hash signal input epoch; // external_nullifier signal input rln_identifier; // Circuit output signal output y; signal output root; signal output nullifier;","s":"RLN - Circuit","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln---circuit","p":120},{"i":147,"t":"This is done using Shamir's secret sharing. Shamir’s secret sharing is based on idea of splitting a secret into shares. This is how we enable slashing of funds. In this case, we have two shares. If a given identity a0 signals twice in epoch/external nullifier, a1 is the same. For a given RLN app, internal_nullifier then stays the same. x is signal hash which is different, and y is public, so we can reconstruct identity_secret. With the identity secret revealed, this gives access to e.g. financial stake. a_0 = identity_secret // secret S a_1 = poseidonHash([a0, external_nullifier]) y = a_0 + x * a_1 internal_nullifier = poseidonHash([a_1, rln_identifier])","s":"RLN - Shamir's secret sharing","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln---shamirs-secret-sharing","p":120},{"i":149,"t":"This is how RLN is used with Relay/GossipSub protocol. A node registers and locks up funds, and after that it can send messages. It publishes a message containing the Zero Knowledge proof and some other details. Each relayer node listens to the membership contract for new members, and it also keeps track of relevant metadata and merkle tree. Metadata is needed to be able to detect double signaling and perform slashing. Before forwarding a message, it does some verification checks to ensure there are no duplicate messages, ZKP is valid and no double signaling has occured. It is worth noting that this can be combined with peer scoring, for example for duplicate messages or invalid ZK proofs. In line of Waku's goals of modularity, RLN Relay is applied on a specific subset of pubsub and content topics. You can think of it as an extra secure channel.","s":"RLN Relay","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln-relay","p":120},{"i":151,"t":"Where are we with RLN Relay deployment? We've recently launched our second testnet. This is using RLN Relay with a smart contract on Goerli. It integrates with our example p2p chat application, and it does so through three different clients, nwaku, go-waku and js-waku for browsers. This is our first p2p cross-client testnet for RLN Relay. Here's a video that shows a user registering in a browser, signaling through JS-Waku. It then gets relayed to a nwaku node, that verifies the proof. The second video shows what happens in the spam case. when more than one message is sent in a given epoch, it detects it as spam and discards it. Slashing hasn't been implemented fully yet in the client and is a work in progress. If you are curious and want to participate, you can join the effort on our Vac Discord. We also have tutorials setup for all clients so you can play around with it. As part of this, and to make it work in multiple different environments, we've also been developing a new library called Zerokit. I'll talk about this a bit later.","s":"RLN Relay cross-client testnet","u":"/rlog/building-privacy-protecting-infrastructure","h":"#rln-relay-cross-client-testnet","p":120},{"i":153,"t":"Going back to the service network idea, let's talk about service credentials. The idea behind service credentials and private settlement is to enable two actors to pay for and provide services without compromising their privacy. We do not want the payment to create a direct public link between the service provider and requester. Recall the Waku service network illustration with adaptive nodes that choose which protocols they want to run. Many of these protocols aren't very heavy and just work by default. For example the relay protocol is enabled by default. Other protocols are much heavier to provide, such as storing historical messages. It is desirable to have additional incentives for this, especially for platforms that aren't community-based where some level of altruism can be assumed (e.g. Status Communities, or WalletConnect cloud infrastructure). You have a node Alice that is often offline and wants to consume historical messages on some specific content topics. You have another node Bob that runs a server at home where they store historical messages for the last several weeks. Bob is happy to provide this service for free because he's excited about running privacy-preserving infrastructure and he's using it himself, but his node is getting overwhelmed by freeloaders and he feels like he should be paid something for continuing to provide this service. Alice deposits some funds in a smart contract which registers it in a tree, similar to certain other private settlement mechanisms. A fee is taken or burned. In exchange, she gets a set of tokens or service credentials. When she wants to do a query with some criteria, she sends this to Bob. Bob responds with size of response, cost, and receiver address. Alice then sends a proof of delegation of a service token as a payment. Bob verifies the proof and resolves the query. The end result is that Alice has consumed some service from Bob, and Bob has received payment for this. There's no direct transaction link between Alice and Bob, and gas fees can be minimized by extending the period before settling on chain. This can be complemented with altruistic service provisioning, for example by splitting the peer pool into two slots, or only providing a few cheap queries for free. The service provisioning is general, and can be generalized for any kind of request/response service provisoning that we want to keep private. This isn't a perfect solution, but it is an incremental improvement on top of the status quo. It can be augmented with more advanced techniques such as better non-repudiable node reputation, proof of correct service provisioning, etc. We are currently in the raw spec / proof of concept stage of this. We expect to launch a testnet of this later this year or early next year.","s":"Private settlement / Service credentials","u":"/rlog/building-privacy-protecting-infrastructure","h":"#private-settlement--service-credentials","p":120},{"i":155,"t":"Zerokit is a set of Zero Knowledge modules, written in Rust and designed to be used in many different environments. The initial goal is to get the best of both worlds with Circom/Solidity/JS and Rust/ZK ecosystem. This enables people to leverage Circom-based constructs from non-JS environments. For the RLN module, it is using Circom circuits via ark-circom and Rust for scaffolding. It exposes a C FFI API that can be used through other system programming environments, like Nim and Go. It also exposes an experimental WASM API that can be used through web browsers. Waku is p2p infrastructure running in many different environments, such as Nim/JS/Go/Rust, so this a requirement for us. Circom and JS strengths are access to Dapp developers, tooling, generating verification code, circuits etc. Rust strengths is that it is systems-based and easy to interface with other language runtime such as Nim, Go, Rust, C. It also gives access to other Rust ZK ecosystems such as arkworks. This opens door for using other constructs, such as Halo2. This becomes especially relevant for constructs where you don't want to do a trusted setup or where circuits are more complex/custom and performance requirements are higher. In general with Zerokit, we want to make it easy to build and use ZKP in a multitude of environments, such as mobile phones and web browsers. Currently it is too complex to write privacy-protecting infrastructure with ZKPs considering all the languages and tools you have to learn, from JS, Solidity and Circom to Rust, WASM and FFI. And that isn't even touching on things like secure key storage or mobile dev. Luckily more and more projects are working on this, including writing DSLs etc. It'd also be exciting if we can make a useful toolstack for JS-less ZK dev to reduce cognitive overhead, similar to what we have with something like Foundry.","s":"Zerokit","u":"/rlog/building-privacy-protecting-infrastructure","h":"#zerokit","p":120},{"i":157,"t":"I also want to mention a few other things we are doing. One thing is protocol specifications. We think this is very important for p2p infra, and we see a lot of other projects that claim to do it p2p infrastructure but they aren't clear about guarantees or how stable something is. That makes it hard to have multiple implementations, to collaborate across different projects, and to analyze things objectively. Related to that is publishing papers. We've put out three so far, related to Waku and RLN-Relay. This makes it easier to interface with academia. There's a lot of good researchers out there and we want to build a better bridge between academia and industry. Another thing is network privacy. Waku is modular with respect to privacy guarantees, and there are a lot of knobs to turn here depending on specific deployments. For example, if you are running the full relay protocol you currently have much stronger receiver anonymity than if you are running filter protocol from a bandwidth or connectivity-restricted node. We aim to make this pluggable depending on user needs. E.g. mixnets such as Nym come with some trade-offs but are a useful tool in the arsenal. A good mental model to keep in mind is the anonymity trilemma, where you can only pick 2/3 out of low latency, low bandwidth usage and strong anonymity. We are currently exploring Dandelion-like additions to the relay/gossip protocol, which would provide for stronger sender anonymity, especially in a multi-node/botnet attacker model. As part of this we are looking into different parameters choices and general possibilities for lower latency usage. This could make it more amenable for latency sensitive environments, such as validator privacy, for specific threat models. The general theme here is we want to be rigorous with the guarantees we provide, under what conditions and for what threat models. Another thing mentioned earlier is Noise payload encryption, and specifically things like allowing for pairing different devices with e.g. QR codes. This makes it easier for developers to provide secure messaging in many realistic scenarios in a multi-device world.","s":"Other research","u":"/rlog/building-privacy-protecting-infrastructure","h":"#other-research","p":120},{"i":159,"t":"We've gone over what privacy-protecting infrastructure is, why we want it and how we can build it. We've seen how ZK is a fundamental building block for this. We've looked at Waku, the communication layer for Web3, and how it uses Zero Knowledge proofs to stay private and function better. We've also looked at Zerokit and how we can make it easier to do ZKP in different environments. Finally we also looked at some other research we've been doing. All of the things mentioned in this article, and more, is available as write-ups, specs, or discussions on our forum or Github. If you find any of this exciting to work on, feel free to reach out on our Discord. We are also hiring, and we have started expanding into other privacy infrastructure tech like private and provable computation with ZK-WASM.","s":"Summary","u":"/rlog/building-privacy-protecting-infrastructure","h":"#summary","p":120},{"i":161,"t":"Device pairing and secure message exchange using Waku and noise protocol. As the world becomes increasingly connected through the internet, the need for secure and reliable communication becomes paramount. In this article it is described how the Noise protocol can be used as a key-exchange mechanism for Waku. Recently, this feature was introduced in js-waku and go-waku, providing a simple API for developers to implement secure communication protocols using the Noise Protocol framework. These open-source libraries provide a solid foundation for building secure and decentralized applications that prioritize data privacy and security. This functionality is designed to be simple and easy to use, even for developers who are not experts in cryptography. The library offers a clear and concise API that abstracts away the complexity of the Noise Protocol framework and provides an straightforward interface for developers to use. Using this, developers can effortlessly implement secure communication protocols on top of their JavaScript and Go applications, without having to worry about the low-level details of cryptography. One of the key benefits of using Noise is that it provides end-to-end encryption, which means that the communication between two parties is encrypted from start to finish. This is essential for ensuring the security and privacy of sensitive information","s":"Device Pairing in Js-waku and Go-waku","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"","p":160},{"i":163,"t":"In today's digital world, device pairing has become an integral part of our lives. Whether it's connecting our smartphones with other computers or web applications, the need for secure device pairing has become more crucial than ever. With the increasing threat of cyber-attacks and data breaches, it's essential to implement secure protocols for device pairing to ensure data privacy and prevent unauthorized access. To demonstrate how device pairing can be achieved using Waku and Noise, we have examples available at https://examples.waku.org/noise-js/. You can try pairing different devices, such as mobile and desktop, via a web application. This can be done by scanning a QR code or opening a URL that contains the necessary data for a secure handshake. The process works as follows: Actors: Alice the initiator Bob the responder The first step in achieving secure device pairing using Noise and Waku is for Bob generate the pairing information which could be transmitted out-of-band. For this, Bob opens https://examples.waku.org/noise-js/ and a QR code is generated, containing the data required to do the handshake. This pairing QR code is timeboxed, meaning that after 2 minutes, it will become invalid and a new QR code must be generated Alice scans the QR code using a mobile phone. This will open the app with the QR code parameters initiating the handshake process which is described in WAKU2-DEVICE-PAIRING. These messages are exchanged between two devices over Waku to establish a secure connection. The handshake messages consist of three main parts: the initiator's message, the responder's message, and the final message, which are exchanged to establish a secure connection. While using js-noise, the developer is abstracted of this process, since the messaging happens automatically depending on the actions performed by the actors in the pairing process. Both Alice and Bob will be asked to verify each other's identity. This is done by confirming if an 8-digits authorization code match in both devices. If both actors confirm that the authorization code is valid, the handshake concludes succesfully Alice and Bob receive a set of shared keys that can be used to start exchanging encrypted messages. The shared secret keys generated during the handshake process are used to encrypt and decrypt messages sent between the devices. This ensures that the messages exchanged between the devices are secure and cannot be intercepted or modified by an attacker. The above example demonstrates device pairing using js-waku. Additionally, You can also try building and experimenting with other noise implementations like nwaku, or go-waku, with an example available at https://github.com/waku-org/go-waku/tree/master/examples/noise in which the same flow described before is done with Bob (the receiver) using go-waku instead of js-waku.","s":"Device Pairing","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"#device-pairing","p":160},{"i":165,"t":"With its easy to use API built on top of the Noise Protocol framework and the LibP2P networking stack, if you are a developer looking to implement secure messaging in their applications that are both decentralized and censorship resistant, Waku is definitely an excellent choice worth checking out! Waku is also Open source with a MIT and APACHEv2 licenses, which means that developers are encouraged to contribute code, report bugs, and suggest improvements to make it even better. Don't hesitate to try the live example at https://examples.waku.org/noise-js and build your own webapp using https://github.com/waku-org/js-noise, https://github.com/waku-org/js-waku and https://github.com/waku-org/go-waku. This will give you a hands-on experience of implementing secure communication protocols using the Noise Protocol framework in a practical setting. Happy coding!","s":"Conclusion","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"#conclusion","p":160},{"i":167,"t":"Noise handshakes as key-exchange mechanism for Waku Noise Protocols for Waku Payload Encryption Session Management for Waku Noise Device pairing and secure transfers with Noise go-waku Noise's example js-waku Noise's example js-noise go-noise","s":"References","u":"/rlog/device-pairing-in-js-waku-and-go-waku","h":"#references","p":160},{"i":169,"t":"A look at EIP-1459 and the benefits of DNS based discovery. Discovery in p2p networks is the process of how nodes find each other and specific resources they are looking for. Popular discovery protocols, such as Kademlia which utilizes a distributed hash table or DHT, are highly inefficient for resource restricted devices. These methods use short connection windows, and it is quite battery intensive to keep establishing connections. Additionally, we cannot expect a mobile phone for example to synchronize an entire DHT using cellular data. Another issue is how we do the initial bootstrapping. In other words, how does a client find its first node to then discover the rest of the network? In most applications, including Status right now, this is done with a static list of nodes that a client can connect to. In summary, we have a static list that provides us with nodes we can connect to which then allows us to discover the rest of the network using something like Kademlia. But what we need is something that can easily be mutated, guarantees a certain amount of security, and is efficient for resource restricted devices. Ideally our solution would also be robust and scalable. How do we do this? EIP 1459: Node Discovery via DNS, which is one of the strategies we are using for discovering waku nodes. EIP-1459 is a DNS-based discovery protocol that stores merkle trees in DNS records which contain connection information for nodes. Waku is our fork of Whisper. Oskar recently wrote an entire post explaining it. In short, Waku is our method of fixing the shortcomings of Whisper in a more iterative fashion. You can find the specification here DNS-based methods for bootstrapping p2p networks are quite popular. Even Bitcoin uses it, but it uses a concept called DNS seeds, which are just DNS servers that are configured to return a list of randomly selected nodes from the network upon being queried. This means that although these seeds are hardcoded in the client, the IP addresses of actual nodes do not have to be. > dig dnsseed.bluematt.me +short 129.226.73.12 107.180.78.111 169.255.56.123 91.216.149.28 85.209.240.91 66.232.124.232 207.55.53.96 86.149.241.168 193.219.38.57 190.198.210.139 74.213.232.234 158.181.226.33 176.99.2.207 202.55.87.45 37.205.10.3 90.133.4.73 176.191.182.3 109.207.166.232 45.5.117.59 178.211.170.2 160.16.0.30 The above displays the result of querying on of these DNS seeds. All the nodes are stored as A records for the given domain name. This is quite a simple solution which Bitcoin almost soley relies on since removing the IRC bootstrapping method in v0.8.2. What makes this DNS based discovery useful? It allows us to have a mutable list of bootstrap nodes without needing to ship a new version of the client every time a list is mutated. It also allows for a more lightweight method of discovering nodes, something very important for resource restricted devices. Additionally, DNS provides us with a robust and scalable infrastructure. This is due to its hierarchical architecture. This hierarchical architecture also already makes it distributed such that the failure of one DNS server does not result in us no longer being able to resolve our name. As with every solution though, there is a trade-off. By storing the list in DNS name an adversary would simply need to censor the DNS records for a specific name. This would prevent any new client trying to join the network from being able to do so. One thing you notice when looking at EIP-1459 is that it is a lot more technically complex than Bitcoin's way of doing this. So if Bitcoin uses this simple method and has proven that it works, why did we need a new method? There are multiple reasons, but the main one is security. In the Bitcoin example, an attacker could create a new list and no one querying would be able to tell. This is however mitigated in EIP-1459 where we can verify the integrity of the entire returned list by storing an entire merkle tree in the DNS records. Let's dive into this. Firstly, a client that is using these DNS records for discovery must know the public key corresponding to the private key controlled by the entity creating the list. This is because the entire list is signed using a secp256k1 private key, giving the client the ability to authenticate the list and know that it has not been tampered with by some external party. So that already makes this a lot safer than the method Bitcoin uses. But how are these lists even stored? As previously stated they are stored using merkle trees as follows: The root of the tree is stored in a TXT record, this record contains the tree's root hash, a sequence number which is incremented every time the tree is updated and a signature as stated above. Additionally, there is also a root hash to a second tree called a link tree, it contains the information to different lists. This link tree allows us to delegate trust and build a graph of multiple merkle trees stored across multiple DNS names. The sequence number ensures that an attacker cannot replace a tree with an older version because when a client reads the tree, they should ensure that the sequence number is greater than the last synchronized version. Using the root hash for the tree, we can find the merkle tree's first branch, the branch is also stored in a TXT record. The branch record contains all the hashes of the branch's leafs. Once a client starts reading all the leafs, they can find one of two things: either a new branch record leading them further down the tree or an Ethereum Name Records (ENR) which means they now have the address of a node to connect to! To learn more about ethereum node records you can have a look at EIP-778, or read a short blog post I wrote explaining them here. Below is the zone file taken from the EIP-1459, displaying how this looks in practice. ; name ttl class type content @ 60 IN TXT enrtree-root:v1 e=JWXYDBPXYWG6FX3GMDIBFA6CJ4 l=C7HRFPF3BLGF3YR4DY5KX3SMBE seq=1 sig=o908WmNp7LibOfPsr4btQwatZJ5URBr2ZAuxvK4UWHlsB9sUOTJQaGAlLPVAhM__XJesCHxLISo94z5Z2a463gA C7HRFPF3BLGF3YR4DY5KX3SMBE 86900 IN TXT enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2@morenodes.example.org JWXYDBPXYWG6FX3GMDIBFA6CJ4 86900 IN TXT enrtree-branch:2XS2367YHAXJFGLZHVAWLQD4ZY,H4FHT4B454P6UXFD7JCYQ5PWDY,MHTDO6TMUBRIA2XWG5LUDACK24 2XS2367YHAXJFGLZHVAWLQD4ZY 86900 IN TXT enr:-HW4QOFzoVLaFJnNhbgMoDXPnOvcdVuj7pDpqRvh6BRDO68aVi5ZcjB3vzQRZH2IcLBGHzo8uUN3snqmgTiE56CH3AMBgmlkgnY0iXNlY3AyNTZrMaECC2_24YYkYHEgdzxlSNKQEnHhuNAbNlMlWJxrJxbAFvA H4FHT4B454P6UXFD7JCYQ5PWDY 86900 IN TXT enr:-HW4QAggRauloj2SDLtIHN1XBkvhFZ1vtf1raYQp9TBW2RD5EEawDzbtSmlXUfnaHcvwOizhVYLtr7e6vw7NAf6mTuoCgmlkgnY0iXNlY3AyNTZrMaECjrXI8TLNXU0f8cthpAMxEshUyQlK-AM0PW2wfrnacNI MHTDO6TMUBRIA2XWG5LUDACK24 86900 IN TXT enr:-HW4QLAYqmrwllBEnzWWs7I5Ev2IAs7x_dZlbYdRdMUx5EyKHDXp7AV5CkuPGUPdvbv1_Ms1CPfhcGCvSElSosZmyoqAgmlkgnY0iXNlY3AyNTZrMaECriawHKWdDRk2xeZkrOXBQ0dfMFLHY4eENZwdufn1S1o All of this has already been introduced into go-ethereum with the pull request #20094, created by Felix Lange. There's a lot of tooling around it that already exists too which is really cool. So if your project is written in Golang and wants to use this, it's relatively simple! Additionally, here's a proof of concept that shows what this might look like with libp2p on github. I hope this was a helpful explainer into DNS based discovery, and shows EIP-1459's benefits over more traditional DNS-based discovery schemes.","s":"DNS Based Discovery","u":"/rlog/dns-based-discovery","h":"","p":168},{"i":171,"t":"In this post, we introduce a crucial data structure used throughout web3.","s":"Vac 101: Climbing Merkle Trees","u":"/rlog/climbing-merkle-trees","h":"","p":170},{"i":173,"t":"A large amount of data is swapped between users on a blockchain in the form of transactions. Over the entire life of a blockchain, the storage space required to maintain a copy of every transaction becomes untenable for most users. However, the integrity of a blockchain relies on a large pool of users that can validate the blockchain's history from its inception to its present state. The data representing the blockchain's state is compressed. This compression addresses the issue of scalability that would otherwise greatly restrict the pool of users. Data compression alone is not the end goal. As mentioned, it is essential for users to be able to validate the blockchain's history. The property of compression and validation was solved in Bitcoin by the use of Merkle trees. Merkle trees were introduced first by Ralph Merkle in his dissertation [1]. A Merkle tree is a data structure that compresses a digest of data to a constant size while still providing a method for proving membership of elements of the digest. A previous rlog[2] described how Merkle trees with their proof of membership could be used for lightweight clients for RLN.","s":"Introduction","u":"/rlog/climbing-merkle-trees","h":"#introduction","p":170},{"i":175,"t":"A tree is a special data structure that organizes nodes so that there is exactly one path between any two nodes. The trees that we consider can be arranged in layers with multiple nodes (children) merged into a single node (parent) in the preceding layer. A single node exists in the base layer; this special node is called the root node. The highest level of the tree consists of childless nodes called leaves. A binary tree has one additional property: each nonleaf node has exactly two children nodes. That is, we assume that nodes in a binary tree are either a parent node with two children or a leaf. As strange as it sounds, each child node has exactly one parental node. A binary tree with 2n2^n2n leaves consists of n+1n+1n+1 layers. Additionally, such a tree has 2n+1−12^{n+1}-12n+1−1 nodes.","s":"Tree structure","u":"/rlog/climbing-merkle-trees","h":"#tree-structure","p":170},{"i":177,"t":"A Merkle tree is a specialized tree in which each node contains the evaluation of a hash function. Merkle trees are usually taken to have a binary tree structure. As such, the presentation we provide in this section will be for binary trees.","s":"Merkle trees","u":"/rlog/climbing-merkle-trees","h":"#merkle-trees","p":170},{"i":179,"t":"In this section, we show how Merkle trees are constructed to compress a digest DDD. Suppose that the digest DDD consists of 2n2^n2n entries; we assume that the digest DDD has this many entries since a Merkle tree is a binary tree. Additionally, each digest can be padded to ensure that DDD has the desired number of entries. Each leaf of the Merkle tree contains the hash of a digest entry. Each parent node contains the hash of the concatenation of their child nodes. Through this iterative construction, we reach the root of the tree. The value contained in the root node is called the root hash. The root hash is a compressed representation of the digest DDD. Each node in the Merkle tree is computed by taking a hash. Since a binary tree with 2n2^n2n leaves has 2n+1−12^{n+1}-12n+1−1 nodes, then we need to evaluate 2n+1−12^{n+1}-12n+1−1 hashes to construct the Merkle tree.","s":"Construction","u":"/rlog/climbing-merkle-trees","h":"#construction","p":170},{"i":181,"t":"A large quantity of data can be compressed to a single hash value. A natural question to ask is: could a clever party find another digest that yields a Merkle tree with the same root hash? If possible, this would compromise the ledger since the blockchain's history could be altered. Fortunately, Merkle trees are quite secure. In fact, Merkle trees can be used to both bind and hide a digest. The Merkle tree is able to bind a digest with one of the properties of hash functions (see our previous Vac 101 [3] for information on hash functions). A hash function is collision resistant; it is infeasible for a malicious party to find two values share the same hash value. This collision resistance property, essentially, fixes the input to each leaf and into their parent, their parent's parent, and so on. In certain applications, it may be desirable for the digest of a Merkle tree to be kept confidential. This is achieved with the preimage resistant property of hash functions. A hash function is preimage resistant provided that it is difficult to reverse the hashing operation. It would be necessary for a malicious party to find preimages to each node starting from the root node to determine the original digest. Now, we see that Merkle trees are secured structures that are tamper resistant.","s":"Merkle tree intregrity","u":"/rlog/climbing-merkle-trees","h":"#merkle-tree-intregrity","p":170},{"i":183,"t":"An interesting and critical property of Merkle trees is their ability to prove that any piece of data is part of its digest. This can be done with logarithmic storage and logarithmic computation time. Suppose that we want to show that data ℓ\\ellℓ is part of the Merkle tree's digest. Additionally, suppose that hash\\mathsf{hash}hash is the hash function used to construct the tree. We assume that the hash function hash\\mathsf{hash}hash can be computed in constant-time for any input. Suppose that a prover provides data ℓ\\ellℓ to a verifier, and tells the verifier that ℓ\\ellℓ corresponds to the iiith leaf of the Merkle tree. For the verifier to be convinced that ℓ\\ellℓ is part of the digest, he needs to be able to construct the tree's root hash using hash\\mathsf{hash}hash, iii, ℓ\\ellℓ and some additional information from the prover. Specifically, the prover must provide the sibling hashes for each value that the verifier can compute. This enables the verifier to compute the parents of the siblings that the prover provides and the values that he was able to produce himself. The last of the computed parents is the root. The leaf index iii indicates whether a hash value provided by the prover is a left or right sibling. This is done by looking at the binary expansion of iii. The verifier can compute the leaf h0=hash(ℓ)h_0 = \\mathsf{hash}(\\ell)h0​=hash(ℓ). Next, using h0h_0h0​'s sibling, h0′h'_0h0′​, provided by the prover, the verifier can compute h1=hash(h0∥h0′)h_1 = \\mathsf{hash}(h_0 \\|h'_0)h1​=hash(h0​∥h0′​) or h1=hash(h0′∥h0)h_1 = \\mathsf{hash}(h'_0 \\| h_0)h1​=hash(h0′​∥h0​) depending on whether h0′h'_0h0′​ is a left or right sibling. This pathing continues until the verifier either successfully computes the root hash (in n+1n+1n+1 hashes) or fails to do so. The prover has to provide nnn sibling nodes for the proof of membership. There is a key detail that is essential for the proof of membership to be secure. The root hash has to be provided to the verifier prior to the selection of data ℓ\\ellℓ. Otherwise, the prover could generate a series of hash values (with the corresponding root hash) to forge a proof of membership. Capped proof of membership​ Polygon provides an implementation [4] of a shortened proof of membership with a slight modification. A specific layer of the Merkle tree is published instead of just the root hash. By doing this, a capped proof of membership is just the path from leaf to the published layer.","s":"Proof of membership","u":"/rlog/climbing-merkle-trees","h":"#proof-of-membership","p":170},{"i":185,"t":"Merkle trees can be extended in multiple ways. In this section, we explore a select few of these extensions.","s":"Extensions of Merkle trees","u":"/rlog/climbing-merkle-trees","h":"#extensions-of-merkle-trees","p":170},{"i":187,"t":"A sparse Merkle tree (SMT) is a special Merkle tree that can be used to represent digests with nonconsecutive entries. Specifically, each digest entry has a particular leaf index. For simplicity, we assume that the index value is computed by taking the hash of the entry. We note that this is a sorted SMT. Let nnn denote the number of bits that a hash value can possess. This means that our SMT can have at most 2n2^n2n leaves. An SMT is treated as a Merkle tree in which each entry is placed in the leaf corresponding to its hash value, and the other entries have a null\\mathsf{null}null marker inserted in. This means that we can prove membership in the way described. However, we can also prove nonmembership of an element by showing that null\\mathsf{null}null is located in the element's hash location. The crucial difference between a sorted and unsorted SMT is that the unsorted variant cannot be used to prove nonmembership. We can take advantage of the sparse nature of SMTs to provide shortened proofs. Specifically, it is unlikely for entries to cluster together. Thus, it is efficient to maintain a list of values: Null values d0:=Hash(null),d_0 := \\mathsf{Hash(null)},d0​:=Hash(null), d1:=Hash(d0∥∥d0),d_1 := \\mathsf{Hash(d_0 \\|\\| d_0)},d1​:=Hash(d0​∥∥d0​), d2:=Hash(d1∥∥d1),d_2 := \\mathsf{Hash(d_1 \\|\\| d_1)},d2​:=Hash(d1​∥∥d1​), ⋮\\vdots⋮ dn−1:=Hash(dn−2∥∥dn−2).d_{n-1} := \\mathsf{Hash(d_{n-2} \\|\\| d_{n-2})}.dn−1​:=Hash(dn−2​∥∥dn−2​). Each of the did_idi​'s represents the root hash of a Merkle tree with 2i2^i2i leaves containing null\\mathsf{null}null. These values can be used to shorten the time needed to construct an SMT and the length of proofs.","s":"Sparse Merkle trees","u":"/rlog/climbing-merkle-trees","h":"#sparse-merkle-trees","p":170},{"i":189,"t":"In the first Vac 101 [5], we examined Bloom and Cuckoo filters that could be used for proof of membership and nonmembership. However, the proof of membership may result in false positives due to collisions. This would affect nonmembership proofs as well. Sparse Merkle trees can be adapted to provide greater assurance that a given piece of data is not a member of the digest. Why is sorting essential? The sorting mechanism of data can be arbitrarily chosen. However, it is essential that there are no gaps in the ordering. The maximum number of elements that could ever exist in the digest must be known. A simple method for this is to use a hash function to provide fingerprints to the data. Each hash using either SHA-256 or Keccak has 256-bits. Our entire digest could consist of a maximum of 22562^{256}2256 entries. This assumes that our digest does not contain collisions. The fingerprint of a piece of data ℓ\\ellℓ indicates which leaf of the SMT it is contained in. This means that a nonmembership of ℓ\\ellℓ in the SMT becomes a matter of proving that null\\mathsf{null}null is contained in ℓ\\ellℓ's location. It is crucial for the SMT to be sorted. Otherwise, a malicious party can append the entry ℓ\\ellℓ to a random location. This allows for the malicious party to provide contradictory proofs that prove both membership and nonmembership. We note that the requirement that an SMT is sorted may be too strong of an assumption in centralized cases. However, sortedness is a necessary property of SMTs for decentralized systems.","s":"Proof of nonmembership","u":"/rlog/climbing-merkle-trees","h":"#proof-of-nonmembership","p":170},{"i":191,"t":"A proof of membership grows in length as the Merkle tree grows. The most obvious approach to remedy this scalability issue is to use Merkle trees in which each node has more than two children. However, this does not fix the issue. A proof of membership in a kkk-nary Merkle tree [6] (each node has kkk children) has a proof size log⁡k(n)(k−1)\\log_k(n)(k-1)logk​(n)(k−1). The multiple k−1k-1k−1 is the number of silbings that a node has on each layer. Hence, the proof size grows faster than a logarithmic function of the digest size. An alternate approach is to use a different data structure: Verkle trees [6]. A Verkle tree replaces hash functions with polynomial commitments [7, 8]. We will explore Verkle trees in a future Vac 101 edition.","s":"Verkle Trees","u":"/rlog/climbing-merkle-trees","h":"#verkle-trees","p":170},{"i":193,"t":"Secrecy, Authentication, and Public Key Systems Verifying RLN Proofs in Light Clients with Subtrees Vac 101: Transforming an Interactive Protocol to a Noninteractive Argument Capped merkle tree in Plonky2 Vac 101: Membership with Bloom Filters and Cuckoo Filters Verkle Trees Using polynomial commitments to replace state roots KZG polynomial commitments O1 labs' Verkle Tree repo","s":"References","u":"/rlog/climbing-merkle-trees","h":"#references","p":170},{"i":195,"t":"A look at typical ethical shortfalls in the global surveillance tech industry. This is an opinion piece by pseudonymous contributor, circe.","s":"Opinion: Pseudo-ethics in the Surveillance Tech Industry","u":"/rlog/ethics-surveillance-tech","h":"","p":194},{"i":197,"t":"The Vac team aims to provide a public good in the form of freely available, open source tools and protocols for decentralized communication. As such, we value our independence and the usefulness of our protocols for a wide range of applications. At the same time, we realize that all technical development, including ours, has a moral component. As a diverse team we are guided by a shared devotion to the principles of human rights and liberty. This explains why we place such a high premium on security, censorship-resistance and privacy - a stance we share with the wider Status Network. The post below takes a different approach from our usual more technical analyses, by starting to peel back the curtain on the ethical shortfalls of the global surveillance tech industry.","s":"Preface","u":"/rlog/ethics-surveillance-tech","h":"#preface","p":194},{"i":199,"t":"Apple's announcement of their lawsuit against Israel's NSO Group marks the latest in a series of recent setbacks for the surveillance tech company. In early November, the United States blacklisted the firm, citing concerns about the use of their spyware by foreign governments targeting civilians such as \"journalists, businesspeople, activists\" and more. The company is already embroiled in a lawsuit with Whatsapp over their exploit of the chat app's video calling service to install malware on target devices. NSO Group's most infamous product, Pegasus, operates as a hidden exploit installed on victims' mobile phones, sometimes without even requiring as much as an unguarded click on a malicious link. It has the potential to lay bare, and report to its owners, everything within the reach of the infected device. For most people this amounts to a significant portion of their private lives and thoughts. Pegasus can read your private messages (even encrypted), collect your passwords, record calls, track your location and access your device's microphone and camera. No activity or application on an infected phone would be hidden. The latest controversies are perhaps less because of the novelty of the revelations - the existence of Pegasus has been known to civil activists since at least 2016. Rather, the public was reminded again of the potential scope of surveillance tech in the indiscriminate use of Pegasus on private citizens. This has far-reaching implications for human freedoms worldwide. Earlier this year, a leaked list of over 50,000 targets, or possible targets, of Pegasus included the phone numbers of human rights advocates, independent journalists, lawyers and political activists. This should have come as no surprise. The type of autocratically inclined agents, and governments, who would venture to buy and use such invasive cyber-arms often target those they find politically inconvenient. Pegasus, and similar technologies, simply extend the reach and capacity of such individuals and governments - no border or distance, no political rank or social advantage, no sanctity of profession or regard for dignity, provide any indemnity from becoming a victim. Your best hope is to remain uninteresting enough to escape consideration. The NSO Group has, of course, denied allegations of culpability and questions the authenticity of the list. At this stage, the latter is almost beside the point: Amnesty International's cybersecurity team, Security Lab, did find forensic evidence of Pegasus on the phones of several volunteers whose numbers appeared on the original list, including those of journalists and human rights activists. (Security Lab has since opened up their infection finding tool to the public.) French intelligence has similarly inspected and confirmed infection of at least three devices belonging to journalists. The phones of several people who were close to the Saudi-American journalist, Jamal Khashoggi, were confirmed hacked both before and after Khashoggi's brutal murder at the Saudi embassy in Istanbul in 2018. More reports of confirmed Pegasus hacks are still published with some regularity. It is now an open secret that many authoritarian governments have bought Pegasus. It's not difficult to extrapolate from existing reports and such clients' track records what the potential injuries to human freedoms are that they can inflict with access to such a powerful cyberweapon.","s":"Spotlight on an industry","u":"/rlog/ethics-surveillance-tech","h":"#spotlight-on-an-industry","p":194},{"i":201,"t":"NSO's response to the allegations follows a textbook approach of avoiding earnest ethical introspection on the manufacturing, and selling, of cyber-arms. Firstly, shift ethical responsibility to a predetermined process, a list of checkboxes of your own making. The Group, for example, claims to sell only to \"vetted governments\", following a classification process of which they have now published some procedural details but no tangible criteria. The next step is to reaffirm continuously, and repetitively, your dedication to the legal combat against crime, \"legitimate law enforcement agencies\" (note the almost tautological phrasing), adherence to international arms trade laws, compliance clauses in customer contracts, etc. Thirdly, having been absolved of any moral suspicions that might exist about product and process, from conception to engineering to trade, distance yourself from the consequences of its use in the world. \"NSO does not operate its technology, does not collect, nor possesses, nor has any access to any kind of data of its customers.\" It is interesting that directly after this statement they claim with contradictory confidence that their \"technology was not associated in any way with the heinous murder of Jamal Khashoggi\". The unapologetic tone seems hardly appropriate when the same document confirms that the Group had to shut down customers' systems due to \"confirmed misuse\" and have had to do so \"multiple times\" in the past. Given all this, the response manages to evade any serious interrogation of the \"vetting\" process itself, which forced the company to reject \"approximately 15% of potential new opportunities for Pegasus\" in one year. Courageous. We have heard this all before. There exists a multi-billion dollar industry of private companies and engineering firms thriving on proceeds from selling surveillance tools and cyber-arms to dubious agencies and foreign governments. In turn, the most power-hungry and oppressive regimes often rely on such technological innovations - for which they lack the in-country engineering expertise - to maintain control, suppress uprisings, intimidate opposing journalists, and track their citizens. It's a lucrative business opportunity, and resourceful companies have sprung up everywhere to supply this demand, often in countries where citizens, including employees of the company, would be horrified if they were similarly subject to the oppressions of their own products. When, in 2014, Italy's HackingTeam were pulsed by the United Nations about their (then alleged) selling of spyware to Sudan, which would have been a contravention of the UN's weapon export ban, they simply replied that their product was not controlled as a weapon and therefore not subject to such scrutiny. They remained within their legal bounds, technically. Furthermore, they similarly shifted ethical responsibility to external standards of legitimacy, claiming their \"software is not sold to governments that are blacklisted by the EU, the US, NATO, and similar international organizations\". When the company themselves were hacked in 2015, revelations (confirmations, that is) of widespread misuse by repressive governments were damaging enough to force them to disappear and rebrand as Memento Labs. Their website boasts an impressive list of statutes, regulations, procedures, export controls and legal frameworks, all of which the rebranded hackers proudly comply with. Surely no further ethical scrutiny is necessary?","s":"A typical response","u":"/rlog/ethics-surveillance-tech","h":"#a-typical-response","p":194},{"i":204,"t":"Such recourse to the legality of your action as ethical justification is moot for several reasons. The first is glaringly obvious - our laws are ill-equipped to address the implications of modern technology. Legal systems are a cumbersome inheritance built over generations. This is especially true of the statutes and regulations governing international trade, behind which these companies so often hide. Our best legal systems are trailing miles behind the technology for which we seek guidelines. Legislators are still struggling to make sense of technologies like face recognition, the repercussions of smart devices acting \"on their own\" and biases in algorithms. To claim you are performing ethical due diligence by resorting to an outdated and incomplete system of legal codes is disingenuous.","s":"The law is trailing behind","u":"/rlog/ethics-surveillance-tech","h":"#the-law-is-trailing-behind","p":194},{"i":206,"t":"The second reason is more central to my argument, and an important flaw in these sleight of hand justifications appearing from time to time in the media. Ethics can in no way be confused as synonymous with legality or legitimacy. These are incommensurable concepts. In an ideal world, of course, the law is meant to track the minimum standards of ethical conduct in a society. Laws are often drafted exactly from some ethical, and practical, impulse to minimize harmful conduct and provide for corrective and punitive measures where transgressions do occur. The law, however, has a much narrower scope than ethics. It can be just or unjust. In fact, it is in need of ethics to constantly reform. Ethics and values are born out of collective self-reflection. It develops in our conversation with ourselves and others about the type of society we strive for. As such, an ethical worldview summarizes our deepest intuitions about how we should live and measure our impact on the world. For this reason, ethics is primarily enforced by social and internal pressures, not legal boundaries - our desire to do what ought to be done, however we define that. Ethics is therefore a much grander scheme than global legal systems and the diplomatic frameworks that grants legitimacy to governments. These are but one limited outflow of the human aspiration to form societies in accordance with our ideologies and ethics.","s":"The law depends on ethics","u":"/rlog/ethics-surveillance-tech","h":"#the-law-depends-on-ethics","p":194},{"i":208,"t":"Of course, the cyber-arms trade has a favorite recourse, international law, which is even more limited. Since such products are seldomly sold to governments and agencies within the country of production, it enables a further distancing from consequences. Many private surveillance companies are based in fairly liberal societies with (seemingly) strict emphases on human rights in their domestic laws. International laws are much more complicated - for opportunists a synonym for \"more grey areas in which to hide\". Company conduct can now be governed, and excused, by a system that follows the whims of autocrats with exploitative intent and vastly different ethical conceptions from the company's purported aims. International law, and the ways it is most often enforced by way of, say, UN-backed sanctions, have long been shaped by the compromises of international diplomacy. To be blunt: these laws are weak and subject to exactly the sort of narrow interests behind which mercenaries have always hidden. The surveillance tech industry is no exception.","s":"International law is vague and exploitable","u":"/rlog/ethics-surveillance-tech","h":"#international-law-is-vague-and-exploitable","p":194},{"i":210,"t":"My point is simple: selling cyber-arms with the potential to become vast tools of oppression to governments and bodies with blatant histories of human rights violations, and all but the publicly announced intention to continue operating in this way, is categorically unconscionable. This seems obvious no matter what ethics system you argue from, provided it harbors any consideration for human dignity and freedom. It is a sign of poor moral discourse that such recourses to law and legitimacy are often considered synonymous with ethical justification. \"I have acted within the bounds of law\", \"We supply only to legitimate law enforcement agencies\", etc. are no substitutes. Ethical conduct requires an honest evaluation of an action against some conception of \"the good\", however you define that. Too often the surveillance tech industry precisely sidesteps this question, both in internal processes and external rationalisations to a concerned public. John Locke, he of the life-liberty-and-property, articulated the idea that government exists solely through the consent of the governed. Towards the end of the 17th century, he wrote in his Second Treatise on Civil Government, \"[w]henever legislators endeavor to take away, and destroy the property of the people, or to reduce them to slavery under arbitrary power, they put themselves in a state of war with the people, who are thereupon absolved from any further obedience\". The inference is straightforward and humanist in essence: legitimacy is not something that is conferred by governments and institutions. Rather, they derive their legitimacy from us, their citizens, holding them to standards of ethics and societal ideals. This legitimacy only remains in tact as long as this mandate is honored and continuously extended by a well-informed public. This is the principle of informed consent on which all reciprocal ethics is based. The surveillance tech industry may well have nothing more or less noble in mind than profit-making within legal bounds when developing and selling their products. However, when such companies are revealed again and again to have supplied tools of gross human rights violations to known human rights violators, they will do well to remember that ethics always precedes requirements of legality and legitimacy. It is a fallacy to take normative guidance from the concept of \"legitimacy\" if the concept itself depends on such normative guidelines for definition. Without examining the ethical standards by which institutions, governments, and laws, were created, no value-judgements about their legitimacy can be made. Hiding behind legal compliance as substitute for moral justification is not enough. Targets of increasingly invasive governmental snooping are too often chosen precisely to suppress the mechanisms from which the legitimacy of such governments flow - the consent of ordinary civilians. Free and fair elections, free speech, free media, freedom of thought are all at risk.","s":"Conclusion","u":"/rlog/ethics-surveillance-tech","h":"#conclusion","p":194},{"i":212,"t":"Status Principles Federal Register: Addition of Certain Entities to the Entity List forbiddenstories.org: The Pegasus Project theguardian.com: The Pegasus Project amnesty.org Forensic Methodology Report: How to catch NSO Group’s Pegasus Apple sues NSO Group to curb the abuse of state-sponsored spyware bbc.com: Who are the hackers who cracked the iPhone? bbc.com: Pegasus: Who are the alleged victims of spyware targeting? citizenlab.ca: Mapping Hacking Team’s “Untraceable” Spyware economist.com: Offering software for snooping to governments is a booming business Memento Labs Mobile Verification Toolkit to identify compromised devices NSO Group: Transparency and Responsibility Report 2021 reuters.com: WhatsApp sues Israel's NSO for allegedly helping spies hack phones around the world wired.com: Hacking Team Breach Shows a Global Spying Firm Run Amok","s":"References","u":"/rlog/ethics-surveillance-tech","h":"#references","p":194},{"i":214,"t":"Looking at discv5 and the theoretical numbers behind finding peers. Disclaimer: some of the numbers found in this write-up could be inaccurate. They are based on the current understanding of theoretical parts of the protocol itself by the author and are meant to provide a rough overview rather than bindable numbers. This post serves as a more authoritative overview of the discv5 study, for a discussionary post providing more context make sure to check out the corresponding discuss post. Additionally, if you are unfamiliar with discv5, check out my previous write-up: \"From Kademlia to Discv5\".","s":"Feasibility Study: Discv5","u":"/rlog/feasibility-discv5","h":"","p":213},{"i":216,"t":"The discovery method currently used by Status, is made up of various components and grew over time to solve a mix of problems. We want to simplify this while maintaining some of the properties we currently have. Namely, we want to ensure censorship resistance to state-level adversaries. One of the issues Status had which caused us them add to their discovery method was the fact that addresses from providers like AWS and GCP were blocked both in Russia and China. Additionally, one of the main factors required is the ability to function on resource restricted devices. Considering we are talking about resource restricted devices, let's look at the implications and what we need to consider: Battery consumption - constant connections like websockets consume a lot of battery life. CPU usage - certain discovery methods may be CPU incentive, slowing an app down and making it unusable. Bandwidth consumption - a lot of users will be using data plans, the discovery method needs to be efficient in order to accommodate those users without using up significant portions of their data plans. Short connection windows - the discovery algorithm needs to be low latency, that means it needs to return results fast. This is because many users will only have the app open for a short amount of time. Not publicly connectable - There is a good chance that most resource restricted devices are not publicly connectable. For a node to be able to participate as both a provider, and a consumer in the discovery method. Meaning a node both reads from other nodes' stored DHTs and hosts the DHT for other nodes to read from, it needs to be publically connectable. This means another node must be able to connect to some public IP of the given node. With devices that are behind a NAT, this is easier said than done. Especially mobile devices, that when connected to 4G LTE networks are often stuck behind a symmetric NAT, drastically reducing the the succeess rate of NAT traversal. Keeping this in mind, it becomes obvious that most resource restricted devices will be consumers rather than providers due to this technical limitation. In order to answer our questions, we formulated the problem with a simple method for testing. The \"needle in a haystack\" problem was formulated to figure out how easily a specific node can be found within a given network. This issue was fully formulated in vacp2p/research#15.","s":"Motivating Problem","u":"/rlog/feasibility-discv5","h":"#motivating-problem","p":213},{"i":218,"t":"The main things we wanted to investigate was the overhead on finding a peer. This means we wanted to look at both the bandwidth, latency and effectiveness of this. There are 2 methods which we can use to find a peer: We can find a peer with a specific ID, using normal lookup methods as documented by Kademlia. We can find a peer that advertises a capability, this is possible using either capabilities advertised in the ENR or through topic tables.","s":"Overview","u":"/rlog/feasibility-discv5","h":"#overview","p":213},{"i":220,"t":"To be able to investigate the feasibility of discv5, we used various methods including rough calculations which can be found in the notebook, and a simulation isolated in vacp2p/research#19.","s":"Feasbility","u":"/rlog/feasibility-discv5","h":"#feasbility","p":213},{"i":222,"t":"The experimental discv5 has already been used within Status, however what was noticed was that the CPU and memory usage was rather high. It therefore should be investiaged if this is still the case, and if it is, it should be isolated where this stems from. Additionally it is worth looking at whether or not this is the case with both the go and nim implementation. See details: vacp2p/research#31","s":"CPU & Memory Usage","u":"/rlog/feasibility-discv5","h":"#cpu--memory-usage","p":213},{"i":224,"t":"If a peer is not publically connectable it can not participate in the DHT both ways. A lot of mobile phones are behind symmetric NATs which UDP hole-punching close to impossible. It should be investigated whether or not mobile phones will be able to participate both ways and if there are good methods for doing hole-punching. See details: vacp2p/research#29","s":"NAT on Cellular Data","u":"/rlog/feasibility-discv5","h":"#nat-on-cellular-data","p":213},{"i":226,"t":"Topic Tables allow us the ability to efficiently find nodes given a specific topic. However, they are not implemented in the status-im/nim-eth implementation nor are they fully finalized in the spec. These are important if the network grows past a size where the concentration of specific nodes is relatively low making them hard to find. See details: vacp2p/research#26","s":"Topic Tables","u":"/rlog/feasibility-discv5","h":"#topic-tables","p":213},{"i":228,"t":"It is important to note, that given a network is relatively small sized, eg 100-500 nodes, then finding a node given a specific address is relatively managable. Additionally, if the concentration of a specific capability in a network is reasonable, then finding a node advertising its capabilities using an ENR rather than the topic table is also managable. A reasonable concentration for example would be 10%, which would give us an 80% chance of getting a node with that capability in the first lookup request. This can be explored more using our discv5 notebook.","s":"Finding a node","u":"/rlog/feasibility-discv5","h":"#finding-a-node","p":213},{"i":230,"t":"Research has shown that finding a node in the DHT has a relatively low effect on bandwidth, both inbound and outbound. For example when trying to find a node in a network of 100 nodes, it would take roughly 5668 bytes total. Additionally if we assume 100ms latency per request it would range at ≈ 300ms latency, translating to 3 requests to find a specific node.","s":"Results","u":"/rlog/feasibility-discv5","h":"#results","p":213},{"i":232,"t":"One of the main blockers right now is figuring out what the CPU and memory usage of discv5 is on mobile phones, this is a large blocker as it affects one of the core problems for us. We need to consider whether discv5 is an upgrade as it allows us to simplify our current discovery process or if it is too much of an overhead for resource restricted devices. The topic table feature could largely enhance discovery however it is not yet implemented. Given that CPU and memory isn't too high, discv5 could probably be used as the other issues are more \"features\" than large scale issues. Implementing it would already reduce the ability for state level adversaries to censor our nodes.","s":"General Thoughts","u":"/rlog/feasibility-discv5","h":"#general-thoughts","p":213},{"i":234,"t":"Oskar Thoren Dmitry Shmatko Kim De Mey Corey Petty","s":"Acknowledgements","u":"/rlog/feasibility-discv5","h":"#acknowledgements","p":213},{"i":236,"t":"Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like. Waku is preparing for production with a focus on the Status Communities use case. In this blog post, we will provide an overview of recent discussions and research outputs, aiming to give you a better understanding of how the Waku network may look like in terms of scaling and incentivization.","s":"The Future of Waku Network: Scaling, Incentivization, and Heterogeneity","u":"/rlog/future-of-waku-network","h":"","p":235},{"i":238,"t":"Waku is actively exploring DOS mitigation mechanisms suitable for Status Communities. While RLN (Rate Limiting Nullifiers) remains the go-to DOS protection solution due to its privacy-preserving and censorship-resistant properties, there is still more work to be done. We are excited to collaborate with PSE (Privacy & Scaling Explorations) in this endeavor. Learn more about their latest progress in this tweet.","s":"DOS Mitigation for Status Communities","u":"/rlog/future-of-waku-network","h":"#dos-mitigation-for-status-communities","p":235},{"i":240,"t":"As we noted in a previous forum post, Waku's protocol incentivization model needs to be flexible to accommodate various business models. Flexibility ensures that projects can choose how they want to use Waku based on their specific needs.","s":"A Heterogeneous Waku Network","u":"/rlog/future-of-waku-network","h":"#a-heterogeneous-waku-network","p":235},{"i":242,"t":"Traditionally, the question of incentivization revolves around how to incentivize operators to run nodes. We'd like to reframe the question and instead ask, \"How do we pay for the infrastructure?\" Waku does not intend to offer a free lunch. Ethereum's infrastructure is supported by transaction fees and inflation, with validators receiving rewards from both sources. However, this model does not suit a communication network like Waku. Users and platforms would not want to pay for every single message they send. Additionally, Waku aims to support instant ephemeral messages that do not require consensus or long-term storage. Projects that use Waku to enable user interactions, whether for chat messages, gaming, private DeFi, notifications, or inter-wallet communication, may have different value extraction models. Some users might provide services for the project and expect to receive value by running nodes, while others may pay for the product or run infrastructure to contribute back. Waku aims to support each of these use cases, which means there will be various ways to \"pay for the infrastructure.\" In his talk, Oskar addressed two strategies: RLN and service credentials.","s":"Reversing the Incentivization Question","u":"/rlog/future-of-waku-network","h":"#reversing-the-incentivization-question","p":235},{"i":244,"t":"RLN enables DOS protection across the network in a privacy-preserving and permission-less manner: stake in a contract, and you can send messages. Service credentials establish a customer-provider relationship. Users might pay to have messages they are interested in stored and served by a provider. Alternatively, a community owner could pay a service provider to host their community. Providers could offer trial or limited free services to Waku users, similar to Slack or Discord. Once a trial is expired or outgrown, a community owner could pay for more storage or bandwidth, similar to Slack's model. Alternatively, individual users could contribute financially, akin to Discord's Server Boost, or by sharing their own resources with their community. We anticipate witnessing various scenarios across the spectrum: from users sharing resources to users paying for access to the network and everything in between.","s":"RLN and Service Credentials","u":"/rlog/future-of-waku-network","h":"#rln-and-service-credentials","p":235},{"i":246,"t":"Another perspective is to consider whether the Waku network will resemble Ethereum or Cosmos. For those not familiar with the difference between both, in a very concise manner: Ethereum is a set of protocols and software that are designed to operate on one common network and infrastructure Cosmos is a set of protocols and software (SDKs) designed to be deployed in separate yet interoperable networks and infrastructures by third parties We want Waku to be decentralized to provide censorship resistance and privacy-preserving communication. If each application has to deploy its own network, we will not achieve this goal. Therefore, we aim Waku to be not only an open source set of protocols, but also a shared infrastructure that anyone can leverage to build applications on top, with some guarantees in terms of decentralization and anonymity. This approach is closer in spirit to Ethereum than Cosmos. Do note that, similarly to Ethereum, anyone is free to take Waku software and protocols and deploy their own network. Yet, because of the difference in the fee model, the Waku Network is unlikely to be as unified as Ethereum's. We currently assume that there will be separate gossipsub networks with different funding models. Since there is no consensus on Waku, each individual operator can decide which network to support, enabling Waku to maintain its permission-less property. Most likely, the Waku network will be heterogeneous, and node operators will choose the incentivization model they prefer.","s":"Waku Network: Ethereum or Cosmos?","u":"/rlog/future-of-waku-network","h":"#waku-network-ethereum-or-cosmos","p":235},{"i":248,"t":"To enable scalability, the flow of messages in the Waku network will be divided in shards, so that not every node has to forward every message of the whole network. Discovery protocols will facilitate users connecting to the right nodes to receive the messages they are interested in. Different shards could be subject to a variety of rate limiting techniques (globally, targeted to that shard or something in-between). Marketplace protocols may also be developed to help operators understand how they can best support the network and where their resources are most needed. However, we are still far from establishing or even assert that such a marketplace will be needed.","s":"Scalability and Discovery Protocols","u":"/rlog/future-of-waku-network","h":"#scalability-and-discovery-protocols","p":235},{"i":250,"t":"Splitting traffic between shards reduces bandwidth consumption for every Waku Relay node. This improvement increases the likelihood that users with home connections can participate and contribute to the gossipsub network without encountering issues. However, it does not cap traffic. There are still open problems regarding how to guarantee that someone can use Waku with lower Internet bandwidth or run critical services, such as a validation node, on the same connection. We have several ongoing initiatives: Analyzing the Status Community protocol to confirm efficient usage of Waku [4] Simulating the Waku Network to measure actual bandwidth usage [5] Segregating chat messages from control and media messages [6] The final solution will likely be a combination of protocols that reduce bandwidth usage or mitigate the risk of DOS attacks, providing flexibility for users and platforms to enable the best experience.","s":"Open Problems","u":"/rlog/future-of-waku-network","h":"#open-problems","p":235},{"i":252,"t":"The definition of the \"Waku Network\" will likely change over time. In the near future, it will transition from a single gossipsub network to a sharded set of networks unified by a common discovery layer. This change will promote scalability and allow various payment models to coexist within the Waku ecosystem. In conclusion, the future of Waku Network entails growth, incentivization, and heterogeneity while steadfastly maintaining its core principles. As Waku continues to evolve, we expect it to accommodate a diverse range of use cases and business models, all while preserving privacy, resisting censorship, avoiding surveillance, and remaining accessible to devices with limited resources.","s":"The Evolving Waku Network","u":"/rlog/future-of-waku-network","h":"#the-evolving-waku-network","p":235},{"i":254,"t":"WAKU2-RELAY-SHARDING 57/STATUS-Simple-Scaling RLN-V2 Scaling Status Communities: Potential Problems Waku Network Testing WAKU2-RELAY-SHARDING: Control Message Shards","s":"References","u":"/rlog/future-of-waku-network","h":"#references","p":235},{"i":256,"t":"A research log. Zero knowledge signaling as a rate limiting mechanism to prevent spam in p2p networks. tldr: Moon math promising for solving spam in Whisper, but to get there we need to invest more in performance work and technical upskilling.","s":"Feasibility Study: Semaphore rate limiting through zkSNARKs","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"","p":255},{"i":258,"t":"In open p2p networks for messaging, one big problem is spam-resistance. Existing solutions, such as Whisper's proof of work, are insufficient, especially for heterogeneous nodes. Other reputation-based approaches might not be desirable, due to issues around arbitrary exclusion and privacy. One possible solution is to use a right-to-access staking-based method, where a node is only able to send a message, signal, at a certain rate, and otherwise they can be slashed. One problem with this is in terms of privacy-preservation, where we specifically don't want a user to be tied to a specific payment or unique fingerprint.","s":"Motivating problem","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#motivating-problem","p":255},{"i":260,"t":"In addition to above, there are a lot of related problems that share similarities in terms of their structure and proposed solution. Private transactions (Zcash, AZTEC) Private voting (Semaphore) Private group membership (Semaphore) Layer 2 scaling, poss layer 1 (ZK Rollup; StarkWare/Eth2-3)","s":"Related problems","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#related-problems","p":255},{"i":263,"t":"A zero-knowledge proof allows a prover to show a verifier that they know something, without revealing what that something is. This means you can do trust-minimized computation that is also privacy preserving. As a basic example, instead of showing your ID when going to a bar you simply give them a proof that you are over 18, without showing the doorman your id. zkSNARKs is a form of zero-knowledge proofs. There are many types of zero-knowledge proofs, and the field is evolving rapidly. They come with various trade-offs in terms of things such as: trusted setup, cryptographic assumptions, proof/verification key size, proof/verification time, proof size, etc. See section below for more. Semaphore is a framework/library/construct on top of zkSNARks. It allows for zero-knowledge signaling, specifically on top of Ethereum. This means an approved user can broadcast some arbitrary string without revealing their identity, given some specific constraints. An approved user is someone who has been added to a certain merkle tree. See current Github home for more. Circom is a DSL for writing arithmetic circuits that can be used in zkSNARKs, similar to how you might write a NAND gate. See Github for more.","s":"Basic terminology","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#basic-terminology","p":255},{"i":265,"t":"We start with a private voting example, and then extend it to the slashable rate limiting example. A user registers an identity (arbitrary keypair), along with a small fee, to a smart contract. This adds them to a merkle tree and allows them to prove that they are member of that group, without revealing who they are. When a user wants to send a message, they compute a zero-knowledge proof. This ensures certain invariants, have some public outputs, and can be verified by anyone (including a smart contract). Any node can verify the proof, including smart contracts on chain (as of Byzantinum HF). Additionally, a node can have rules for the public output. In the case of voting, one such rule is that a specific output hash has to be equal to some predefined value, such as \"2020-01-01 vote on Foo Bar for president\". Because of how the proof is constructed, and the rules around output values, this ensures that: a user is part of the approved set of voters and that a user can only vote once. As a consequence of above, we have a system where registered users can only vote once, no one can see who voted for what, and this can all be proven and verified.","s":"Basic flow","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#basic-flow","p":255},{"i":267,"t":"In the case of rate limiting, we do want nodes to send multiple messages. This changes step 3-5 above somewhat. NOTE: It is a bit more involved than this, and if we precompute proofs the flow might look a bit different. But the general idea is the same. Instead of having a rule that you can only vote once, we have a rule that you can only send a message per epoch. Epoch here can be every second, as defined by UTC date time +-20s. Additionally, if a users sends more than one message per epoch, one of the public outputs is a random share of a private key. Using Shamir's Secret Sharing (similar to a multisig) and 2/3 key share as an example threshold: in the normal case only 1/3 private keys is revealed, which is insufficient to have access. In the case where two messages are sent in an epoch, probabilistically 2/3 shares is sufficient to have access to the key (unless you get the same random share of the key). This means any untrusted user who detects a spamming user, can use it to access their private key corresponding to funds in the contract, and thus slash them. As a consequence of above, we have a system where registered users can only messages X times per epoch, and no one can see who is sending what messages. Additionally, if a user is violating the above rate limit, they can be punished and any user can profit from it.","s":"Rate limiting example","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#rate-limiting-example","p":255},{"i":269,"t":"In the case of an application like Status, this construct can either be a global StatusNetwork group, or one per chat, or network, etc. It can be applied both at the network and user level. There are no specific limitations on where or who deploys this, and it is thus more of a UX consideration.","s":"Briefly on scope of 'approved users'","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#briefly-on-scope-of-approved-users","p":255},{"i":271,"t":"For a fairly self-contained set of examples above, see exploration in Vac research repo. Note that the Shamir secret sharing is not inside the SNARK, but out-of-band for now. The current version of Semaphore is using NodeJS and Circom from Iden3 for Snarks. For more on rate limiting idea, see ethresearch post.","s":"Technical details","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#technical-details","p":255},{"i":273,"t":"The above repo was used to exercise the basic paths and to gain intution of feasibility. Based on it and related reading we outline a few blockers and things that require further study.","s":"Feasibility","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#feasibility","p":255},{"i":275,"t":"Proof time​ Prove time for Semaphore (https://github.com/kobigurk/semaphore) zKSNARKs using circom, groth and snarkjs is currently way too long. It takes on the order of ~10m to generate a proof. With Websnark, it is likely to take 30s, which might still be too long. We should experiment with native code on mobile here. See details. Proving key size​ Prover key size is ~110mb for Semaphore. Assuming this is embedded on mobile device, it bloats the APK a lot. Current APK size is ~30mb and even that might be high for people with limited bandwidth. See details. Trusted setup​ Using zkSNARKs a trusted setup is required to generate prover and verifier keys. As part of this setup, a toxic parameter lambda is generated. If a party gets access to this lambda, they can prove anything. This means people using zKSNARKs usually have an elaborate MPC ceremony to ensure this parameter doesn't get discovered. See details. Shamir logic in SNARK​ For Semaphore RLN we need to embed the Shamir logic inside the SNARK in order to do slashing for spam. Currently the implementation is trusted and very hacky. See details. End to end integation​ Currently is standalone and doesn't touch multiple users, deployed contract with merkle tree and verification, actual transactions, a mocked network, add/remove members, etc. There are bound to be edge cases and unknown unknowns here. See details. Licensing issues​ Currently Circom uses a GPL license, which can get tricky when it comes to the App Store etc. See details. Alternative ZKPs?​ Some of the isolated blockers for zKSNARKs (#7, #8, #9) might be mitigated by the use of other ZKP technology. However, they likely have their own issues. See details.","s":"Technical feasibility","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#technical-feasibility","p":255},{"i":277,"t":"Technical skill​ zkSNARKs and related technologies are quite new. To learn how they work and get an intuition for them requires individuals to dedicate a lot of time to studying them. This means we must make getting competence in these technologies if we wish to use them to our advantage. Time and resources​ In order for this and related projects (such as private transaction) to get anywhere, it must be made an explicit area of focus for an extend period of time.","s":"Social feasibility","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#social-feasibility","p":255},{"i":279,"t":"Similar to Whisper, and in line with moving towards protocol and infrastructure, we need to upskill and invest resources into this. This doesn't mean developing all of the technologies ourselves, but gaining enough competence to leverage and extend existing solutions by the growing ZKP community. For example, this might also include leveraging largely ready made solutions such as AZTEC for private transaction; more fundamental research into ZK rollup and similar; using Semaphore for private group membership and private voting; Nim based wrapper aronud Bellman, etc.","s":"General thoughts","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#general-thoughts","p":255},{"i":281,"t":"Thanks to Barry Whitehat for patient explanation and pointers. Thanks to WJ for helping with runtime issues. _Peacock header image from Tonos._","s":"Acknowledgement","u":"/rlog/feasibility-semaphore-rate-limiting-zksnarks","h":"#acknowledgement","p":255},{"i":283,"t":"A research log. Why Whisper doesn't scale and how to fix it. This post will introduce Waku. Waku is a fork of Whisper that attempts to addresses some of Whisper's shortcomings in an iterative fashion. We will also introduce a theoretical scaling model for Whisper that shows why it doesn't scale, and what can be done about it.","s":"Fixing Whisper with Waku","u":"/rlog/fixing-whisper-with-waku","h":"","p":282},{"i":285,"t":"Whisper is a gossip-based communication protocol or an ephemeral key-value store depending on which way you look at it. Historically speaking, it is the messaging pilllar of Web3, together with Ethereum for consensus and Swarm for storage. Whisper, being a somewhat esoteric protocol and with some fundamental issues, hasn't seen a lot of usage. However, applications such as Status are using it, and have been making minor ad hoc modifications to it to make it run on mobile devices. What are these fundamental issues? In short: scalability, most immediately when it comes to bandwidth usage spam-resistance, proof of work is a poor mechanism for heterogeneous nodes no incentivized infrastructure, leading to centralized choke points lack of formal and unambiguous specification makes it hard to analyze and implement running over devp2p, which limits where it can run and how In this post, we'll focus on the first problem, which is scalability through bandwidth usage.","s":"Introduction","u":"/rlog/fixing-whisper-with-waku","h":"#introduction","p":282},{"i":287,"t":"(Feel free to skip this section if you want to get right to the results). There's widespread implicit knowledge that Whisper \"doesn't scale\", but it is less understood exactly why. This theoretical model attempts to encode some characteristics of it. Specifically for use case such as one by Status (see Status Whisper usage spec).","s":"Whisper theoretical scalability model","u":"/rlog/fixing-whisper-with-waku","h":"#whisper-theoretical-scalability-model","p":282},{"i":289,"t":"First, some caveats: this model likely contains bugs, has wrong assumptions, or completely misses certain dimensions. However, it acts as a form of existence proof for unscalability, with clear reasons. If certain assumptions are wrong, then we can challenge them and reason about them in isolation. It doesn’t mean things will definitely work as the model predicts, and that there aren’t unknown unknowns. The model also only deals with receiving bandwidth for end nodes, uses mostly static assumptions of averages, and doesn’t deal with spam resistance, privacy guarantees, accounting, intermediate node or network wide failures.","s":"Caveats","u":"/rlog/fixing-whisper-with-waku","h":"#caveats","p":282},{"i":291,"t":"Ensure network scales by being user or usage bound, as opposed to bandwidth growing in proportion to network size. Staying with in a reasonable bandwidth limit for limited data plans. Do the above without materially impacting existing nodes. It proceeds through various case with clear assumptions behind them, starting from the most naive assumptions. It shows results for 100 users, 10k users and 1m users.","s":"Goals","u":"/rlog/fixing-whisper-with-waku","h":"#goals","p":282},{"i":293,"t":"Case 1. Only receiving messages meant for you [naive case] Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A4. Only receiving messages meant for you. For 100 users, receiving bandwidth is 1000.0KB/day For 10k users, receiving bandwidth is 1000.0KB/day For 1m users, receiving bandwidth is 1000.0KB/day ------------------------------------------------------------ Case 2. Receiving messages for everyone [naive case] Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A5. Received messages for everyone. For 100 users, receiving bandwidth is 97.7MB/day For 10k users, receiving bandwidth is 9.5GB/day For 1m users, receiving bandwidth is 953.7GB/day ------------------------------------------------------------ Case 3. All private messages go over one discovery topic [naive case] Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A6. Proportion of private messages (static): 0.5 - A7. Public messages only received by relevant recipients (static). - A8. All private messages are received by everyone (same topic) (static). For 100 users, receiving bandwidth is 49.3MB/day For 10k users, receiving bandwidth is 4.8GB/day For 1m users, receiving bandwidth is 476.8GB/day ------------------------------------------------------------ Case 4. All private messages are partitioned into shards [naive case] Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A6. Proportion of private messages (static): 0.5 - A7. Public messages only received by relevant recipients (static). - A9. Private messages partitioned across partition shards (static), n=5000 For 100 users, receiving bandwidth is 1000.0KB/day For 10k users, receiving bandwidth is 1.5MB/day For 1m users, receiving bandwidth is 98.1MB/day ------------------------------------------------------------ Case 5. 4 + Bloom filter with false positive rate Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A6. Proportion of private messages (static): 0.5 - A7. Public messages only received by relevant recipients (static). - A9. Private messages partitioned across partition shards (static), n=5000 - A10. Bloom filter size (m) (static): 512 - A11. Bloom filter hash functions (k) (static): 3 - A12. Bloom filter elements, i.e. topics, (n) (static): 100 - A13. Bloom filter assuming optimal k choice (sensitive to m, n). - A14. Bloom filter false positive proportion of full traffic, p=0.1 For 100 users, receiving bandwidth is 10.7MB/day For 10k users, receiving bandwidth is 978.0MB/day For 1m users, receiving bandwidth is 95.5GB/day NOTE: Traffic extremely sensitive to bloom false positives This completely dominates network traffic at scale. With p=1% we get 10k users ~100MB/day and 1m users ~10gb/day) ------------------------------------------------------------ Case 6. Case 5 + Benign duplicate receives Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A6. Proportion of private messages (static): 0.5 - A7. Public messages only received by relevant recipients (static). - A9. Private messages partitioned across partition shards (static), n=5000 - A10. Bloom filter size (m) (static): 512 - A11. Bloom filter hash functions (k) (static): 3 - A12. Bloom filter elements, i.e. topics, (n) (static): 100 - A13. Bloom filter assuming optimal k choice (sensitive to m, n). - A14. Bloom filter false positive proportion of full traffic, p=0.1 - A15. Benign duplicate receives factor (static): 2 - A16. No bad envelopes, bad PoW, expired, etc (static). For 100 users, receiving bandwidth is 21.5MB/day For 10k users, receiving bandwidth is 1.9GB/day For 1m users, receiving bandwidth is 190.9GB/day ------------------------------------------------------------ Case 7. 6 + Mailserver under good conditions; small bloom fp; mostly offline Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A6. Proportion of private messages (static): 0.5 - A7. Public messages only received by relevant recipients (static). - A9. Private messages partitioned across partition shards (static), n=5000 - A10. Bloom filter size (m) (static): 512 - A11. Bloom filter hash functions (k) (static): 3 - A12. Bloom filter elements, i.e. topics, (n) (static): 100 - A13. Bloom filter assuming optimal k choice (sensitive to m, n). - A14. Bloom filter false positive proportion of full traffic, p=0.1 - A15. Benign duplicate receives factor (static): 2 - A16. No bad envelopes, bad PoW, expired, etc (static). - A17. User is offline p% of the time (static) p=0.9 - A18. No bad request, dup messages for mailservers; overlap perfect (static). - A19. Mailserver requests can change false positive rate to be p=0.01 For 100 users, receiving bandwidth is 3.9MB/day For 10k users, receiving bandwidth is 284.8MB/day For 1m users, receiving bandwidth is 27.8GB/day ------------------------------------------------------------ Case 8. No metadata protection w bloom filter; 1 node connected; static shard Aka waku mode. Next step up is to either only use contact code, or shard more aggressively. Note that this requires change of other nodes behavior, not just local node. Assumptions: - A1. Envelope size (static): 1024kb - A2. Envelopes / message (static): 10 - A3. Received messages / day (static): 100 - A6. Proportion of private messages (static): 0.5 - A7. Public messages only received by relevant recipients (static). - A9. Private messages partitioned across partition shards (static), n=5000 For 100 users, receiving bandwidth is 1000.0KB/day For 10k users, receiving bandwidth is 1.5MB/day For 1m users, receiving bandwidth is 98.1MB/day ------------------------------------------------------------ See source for more detail on the model and its assumptions.","s":"Model","u":"/rlog/fixing-whisper-with-waku","h":"#model","p":282},{"i":295,"t":"Whisper as it currently works doesn’t scale, and we quickly run into unacceptable bandwidth usage. There are a few factors of this, but largely it boils down to noisy topics usage and use of bloom filters. Duplicate (e.g. see Whisper vs PSS) and bad envelopes are also factors, but this depends a bit more on specific deployment configurations. Waku mode (case 8) is an additional capability that doesn’t require other nodes to change, for nodes that put a premium on performance. The next bottleneck after this is the partitioned topics (app/network specific), which either needs to gracefully (and potentially quickly) grow, or an alternative way of consuming those messages needs to be deviced. The results are summarized in the graph above. Notice the log-log scale. The colored backgrounds correspond to the following bandwidth usage: Blue: 10mb/d (~300mb/month) Green: 30mb/d (~1gb/month) Yellow: 100mb/d (~3gb/month) Red: >100mb/d (>3gb/month) These ranges are somewhat arbitrary, but are based on user requirements for users on a limited data plan, with comparable usage for other messaging apps.","s":"Takeaways","u":"/rlog/fixing-whisper-with-waku","h":"#takeaways","p":282},{"i":298,"t":"Apps such as Status will likely use something like Whisper for the forseeable future, and we want to enable them to use it with more users on mobile devices without bandwidth exploding with minimal changes. Additionally, there's not a clear cut alternative that maps cleanly to the desired use cases (p2p, multicast, privacy-preserving, open, etc). We are actively researching, developing and collaborating with more greenfield approaches. It is likely that Waku will either converge to those, or Waku will lay the groundwork (clear specs, common issues/components) necessary to make switching to another protocol easier. In this project we want to emphasize iterative work with results on the order of weeks.","s":"Motivation for a new protocol","u":"/rlog/fixing-whisper-with-waku","h":"#motivation-for-a-new-protocol","p":282},{"i":300,"t":"Doesn’t impact existing clients, it’s just a separate node and capability. Other nodes can still use Whisper as is, like a full node. Sacrifices metadata protection and incurs higher connectivity/availability requirements for scalbility Requirements: Exposes API to get messages from a set of list of topics (no bloom filter) Way of being identified as a Waku node (e.g. through version string) Option to statically encode this node in app, e.g. similar to custom bootnodes/mailserver Only node that needs to be connected to, possibly as Whisper relay / mailserver hybrid Provides: likely provides scalability of up to 10k users and beyond with some enhancements to partition topic logic, can possibly scale up to 1m users (app/network specific) Caveats: hasn’t been tested in a large-scale simulation other network and intermediate node bottlenecks might become apparent (e.g. full bloom filter and private cluster capacity; can likely be dealt with in isolation using known techniques, e.g. load balancing) (deployment specific)","s":"Briefly on Waku mode","u":"/rlog/fixing-whisper-with-waku","h":"#briefly-on-waku-mode","p":282},{"i":302,"t":"In short, we have a Waku version 0 spec up as well as a PoC for backwards compatibility. In the coming weeks, we are going to solidify the specs, get a more fully featured PoC for Waku mode. See rough roadmap, project board [link deprecated] and progress thread on the Vac forum. The spec has been rewrittten for clarity, with ABNF grammar and less ambiguous language. The spec also incorporates several previously ad hoc implemented features, such as light nodes and mailserver/client support. This has already caught a few incompatibilities between the geth (Go), status/whisper (Go) and nim-eth (Nim) versions, specifically around light node usage and the handshake. If you are interested in this effort, please check out our forum for questions, comments and proposals. We already have some discussion for better spam protection (see previous post for a more complex but privacy-preserving proposal), something that is likely going to be addressed in future versions of Waku, along with many other fixes and enhancement.","s":"Progress so far","u":"/rlog/fixing-whisper-with-waku","h":"#progress-so-far","p":282},{"i":304,"t":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","s":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","u":"/rlog/GossipSub Improvements","h":"","p":303},{"i":306,"t":"We have been recently working on analyzing and improving the performance of the GossipSub protocol for large messages, as in the case of Ethereum Improvement Proposal EIP-4844. This work led to a comprehensive study of unstructured P2P networks. The intention was to identify the best practices that can serve as guidelines for performance improvement and scalability of P2P networks.","s":"Motivitation","u":"/rlog/GossipSub Improvements","h":"#motivitation","p":303},{"i":308,"t":"Nodes in an unstructured p2p network form self-organizing overlay(s) on top of the IP infrastructure to facilitate different services like information dissemination, query propagation, file sharing, etc. The overlay(s) can be as optimal as a tree-like structure or as enforcing as a fully connected mesh. Due to peer autonomy and a trustless computing environment, some peers may deviate from the expected operation or even leave the network. At the same time, the underlying IP layer is unreliable. Therefore, tree-like overlays are not best suited for reliable information propagation. Moreover, tree-based solutions usually result in significantly higher message dissemination latency due to suboptimal branches. Flooding-based solutions, on the other hand, result in maximum resilience against adversaries and achieve minimal message dissemination latency because the message propagates through all (including the optimal) paths. Redundant transmissions help maintain the integrity and security of the network in the presence of adversaries and high node failure but significantly increase network-wide bandwidth utilization, cramming the bottleneck links. An efficient alternative is to lower the number of redundant transmissions by D-regular broadcasting, where a peer will likely receive (or relay) a message from up to DDD random peers. Publishing through a D-regular overlay triggers approximately N×DN \\times DN×D transmissions. Reducing DDD reduces the redundant transmissions but compromises reachability and latency. Sharing metadata through a K-regular overlay (where K>DK > DK>D) allows nodes to pull missing messages. GossipSub [1] benefits from full-message (D-regular) and metadata-only (k-regular) overlays. Alternatively, a metadata-only overlay can be used, requiring a pull-based operation that significantly minimizes bandwidth utilization at the cost of increased latency. Striking the right balance between parameters like D,KD, KD,K, pull-based operation, etc., can yield application-specific performance tuning, but scalability remains a problem. At the same time, many other aspects can significantly contribute to the network's performance and scalability. One option is to realize peers' suitability and continuously changing capabilities while forming overlays. For instance, a low-bandwidth link near a publisher can significantly demean the entire network's performance. Reshuffling of peering links according to the changing network conditions can lead to superior performance. Laying off additional responsibilities to more capable nodes (super nodes) can alleviate peer cramming, but it makes the network susceptible to adversaries/peer churn. Grouping multiple super nodes to form virtual node(s) can solve this problem. Similarly, flat (single-tier) overlays cannot address the routing needs in large (geographically dispersed) networks. Hierarchical (Multi-tier) overlays with different intra/inter-overlay routing solutions can better address these needs. Moreover, using message aggregation schemes for grouping multiple messages can save bandwidth and provide better resilience against adversaries/peer churn. This article's primary objective is to investigate the possible choices that can empower an unstructured P2P network to achieve superior performance for the broadest set of applications. We look into different constraints imposed by application-specific needs (performance goals) and investigate various choices that can augment the network's performance. We explore overlay designs/freshness, peer selection approaches, message-relaying mechanisms, and resilience against adversaries/peer churn. We consider GossipSub a baseline protocol to explore various possibilities and decisively commit to the ones demonstrating superior performance. We also discuss the current state and, where applicable, propose a strategic plan for embedding new features to the GossipSub protocol.","s":"Introduction","u":"/rlog/GossipSub Improvements","h":"#introduction","p":303},{"i":310,"t":"Different applications, like blockchain, streaming, etc., impose strict time bounds on network-wide message dissemination latency. A message delivered after the imposed time bounds is considered as dropped. An early message delivery in applications like live streaming can further enhance the viewing quality. The properties and nature of the overlay network topology significantly impact the performance of services and applications executed on top of them. Studying and devising mechanisms for better overlay design and message dissemination is paramount to achieving superior performance. Interestingly, shortest-path message delivery trees have many limitations: Changing network dynamics requires a quicker and continuous readjustment of the multicast tree. The presence of resource-constrained (bandwidth/compute, etc.) nodes in the overlay can result in congestion. Node failure can result in partitions, making many segments unreachable. Assuring a shortest-path tree-like structure requires a detailed view of the underlying (and continuously changing) network topology. Solutions involve creating multiple random trees to add redundancy [2]. Alternatives involve building an overlay mesh and forwarding messages through the multicast delivery tree (eager push). Metadata is shared through the overlay links so that the nodes can ask for missing messages (lazy push or pull-based operation) through the overlay links. New nodes are added from the overlay on node failure, but it requires non-faulty node selection. GossipSub uses eager push (through overlay mesh) and lazy push (through IWANT messages). The mesh degree DLow≤D≤DHighD_{Low} \\leq D \\leq D_{High}DLow​≤D≤DHigh​ is crucial in deciding message dissemination latency. A smaller value for DDD results in higher latency due to increased rounds, whereas a higher DDD reduces latency on the cost of increased bandwidth. At the same time, keeping DDD independent of the growing network size (NNN) may increase network-wide message dissemination latency. Adjusting DDD with NNN maintains similar latency on the cost of increased workload for peers. Authors in [3] suggest only a logarithmic increase in DDD to maintain a manageable workload for peers. In [4], it is reported that the average mesh degree should not exceed Davg=ln⁡(N)+CD_{avg} = \\ln(N) + CDavg​=ln(N)+C for an optimal operation, where CCC is a small constant. Moreover, quicker shuffling of peers results in better performance in the presence of resource-constrained nodes or node failure [4].","s":"GOAL1: Low Latency Operation","u":"/rlog/GossipSub Improvements","h":"#goal1-low-latency-operation","p":303},{"i":312,"t":"Random peering connections in P2P overlays represent a stochastic process. It is inherently difficult to precisely model the performance of such systems. Most of the research on P2P networks provides simulation results assuming nodes with similar capabilities. The aspect of dissimilar capabilities and resource-constrained nodes is less explored. It is discussed in GOAL1 that overlay mesh results in better performance if DavgD_{avg}Davg​ does not exceed ln⁡(N)+C\\ln(N) + Cln(N)+C. Enforcing all the nodes to have approximately ln⁡(N)+C\\ln(N) + Cln(N)+C peers makes resource-rich nodes under-utilized, while resource-constrained nodes are overloaded. At the same time, connecting high-bandwidth nodes through a low-bandwidth node undermines the network's performance. Ideally, the workload on any node should not exceed its available resources. A better solution involves a two-phased operation: Every node computes its available bandwidth and selects a node degree DDD proportional to its available bandwidth [4]. Different bandwidth estimation approaches are suggested in literature [5,6]. Simple bandwidth estimation approaches like variable packet size probing [6] yield similar results with less complexity. It is also worth mentioning that many nodes may want to allocate only a capped share of their bandwidth to the network. Lowering DDD according to the available bandwidth can still prove helpful. Additionally, bandwidth preservation at the transport layer through approaches like µTP can be useful. To further conform to the suggested mesh-degree average DavgD_{avg}Davg​, every node tries achieving this average within its neighborhood, resulting in an overall similar DavgD_{avg}Davg​. From the available local view, every node tries connecting peers with the lowest latency until DDD connections are made. We suggest referring to the peering solution discussed in GOAL5 to avoid network partitioning. The current GossipSub design considers homogeneous peers, and every node tries maintaining DLow≤D≤DHighD_{Low} \\leq D \\leq D_{High}DLow​≤D≤DHigh​ connections.","s":"GOAL2: Considering Heterogeneity In Overlay Design","u":"/rlog/GossipSub Improvements","h":"#goal2-considering-heterogeneity-in-overlay-design","p":303},{"i":314,"t":"Redundant message transmissions are essential for handling adversaries/node failure. However, these transmissions result in traffic bursts, cramming many overlay links. This not only adds to the network-wide message dissemination latency but a significant share of the network's bandwidth is wasted on (usually) unnecessary transmissions. It is essential to explore solutions that can minimize the number of redundant transmissions while assuring resilience against node failures. Many efforts have been made to minimize the impact of redundant transmissions. These solutions include multicast delivery trees, metadata sharing to enable pull-based operation, in-network information caching, etc. [7,8]. GossipSub employs a hybrid of eager push (message dissemination through the overlay) and lazy push (a pull-based operation by the nodes requiring information through IWANT messages). A better alternative to simple redundant transmission is to use message aggregation [9,10,11] for the GossipSub protocol. As a result, redundant message transmissions can serve as a critical advantage of the GossipSub protocol. Suppose that we have three equal-length messages x1,x2,x3x1, x2, x3x1,x2,x3. Assuming an XOR coding function, we know two trivial properties: x1⊕x2⊕x2=x1x1 \\oplus x2 \\oplus x2 = x1x1⊕x2⊕x2=x1 and ∣x1∣=∣x1⊕x2⊕x2∣\\vert x1 \\vert = \\vert x1 \\oplus x2 \\oplus x2 \\vert∣x1∣=∣x1⊕x2⊕x2∣. This implies that instead of sending messages individually, we can encode and transmit composite message(s) to the network. The receiver can reconstruct the original message from encoded segments. As a result, fewer transmissions are sufficient for sending more messages to the network. However, sharing linear combinations of messages requires organizing messages in intervals, and devising techniques to identify all messages belonging to each interval. In addition, combining messages from different publishers requires more complex arrangements, involving embedding publisher/message IDs, delayed forwarding (to accommodate more messages), and mechanisms to ensure the decoding of messages at all peers. Careful application-specific need analysis can help decide the benefits against the added complexity.","s":"GOAL3: Bandwidth Optimization","u":"/rlog/GossipSub Improvements","h":"#goal3-bandwidth-optimization","p":303},{"i":316,"t":"Many applications require transferring large messages for their successful operation. For instance, database/blockchain transactions [12]. This introduces two challenges: Redundant large message transmissions result in severe network congestion. Message transmissions follow a store/forward process at all peers, which is inefficient in the case of large messages. The above-mentioned challenges result in a noticeable increase in message dissemination latency and bandwidth wastage. Most of the work done for handling large messages involves curtailing redundant transmissions using multicast delivery trees, reducing the number of fanout nodes, employing in-network message caching, pull-based operation, etc. Approaches like message aggregation also prove helpful in minimizing bandwidth wastage. Our recent work on GossipSub improvements (still a work in progress) suggests the following solutions to deal with large message transmissions: Using IDontWant message proposal [13] and staggered sending. IDontWant message helps curtail redundant transmissions by letting other peers know we have already received the message. Staggered sending enables relaying the message to a short subset of peers in each round. We argue that simultaneously relaying a message to all peers hampers the effectiveness of the IDontWant message. Therefore, using the IDontWant message with staggered sending can yield better results by allowing timely reception and processing of IDontWant messages. Message transmissions follow a store/forward process at all peers that is inefficient in the case of large messages. We can parallelize message transmission by partitioning large messages into smaller fragments, letting intermediate peers relay these fragments as soon as they receive them.","s":"GOAL4: Handling Large Messages","u":"/rlog/GossipSub Improvements","h":"#goal4-handling-large-messages","p":303},{"i":318,"t":"P2P networks are inherently scalable because every incoming node brings in bandwidth and compute resources. In other words, we can keep adding nodes to the network as long as every incoming node brings at-least R×DR \\times DR×D bandwidth, where RRR is average data arrival rate. It is worth mentioning that network-wide message dissemination requires at-least ⌈log⁡D(N)⌉\\lceil \\log_D (N) \\rceil⌈logD​(N)⌉ hops. Therefore, increasing network size increases message dissemination latency, assuming D is independent of the network size. Additionally, problems like peer churn, adversaries, heterogeneity, distributed operation, etc., significantly hamper the network's performance. Most efforts for bringing scalability to the P2P systems have focused on curtailing redundant transmissions and flat overlay adjustments. Hierarchical overlay designs, on the other hand, are less explored. Placing a logical structure in unstructured P2P systems can help scale P2P networks. One possible solution is to use a hierarchical overlay inspired by the approaches [14,15,16]. An abstract operation of such overlay design is provided below: Clustering nodes based on locality, assuming that such peers will have relatively lower intra-cluster latency and higher bandwidth. For this purpose, every node tries connecting peers with the lowest latency until DDD connections are made or the cluster limit is reached. A small subset of nodes having the highest bandwidth and compute resources is selected from each cluster. These super nodes form a fully connected mesh and jointly act as a virtual node, mitigating the problem of peer churn among super nodes. Virtual nodes form a fully connected mesh to construct a hierarchical overlay. Each virtual node is essentially a collection of super nodes; a link to any of the constituent super nodes represents a link to the virtual node. One possible idea is to use GossipSub for intra-cluster message dissemination and FloodSub for inter-cluster message dissemination.","s":"GOAL5: Scalability","u":"/rlog/GossipSub Improvements","h":"#goal5-scalability","p":303},{"i":320,"t":"Overlay acts as a virtual backbone for a P2P network. A flat overlay is more straightforward and allows effortless readjustment to application needs. On the other hand, a hierarchical overlay can bring scalability at the cost of increased complexity. Regardless of the overlay design, a continuous readjustment to appropriate peering links is essential for superior performance. At the same time, bandwidth preservation (through message aggregation, caching at strategic locations, metadata sharing, pull-based operation, etc.) can help minimize latency. However, problems like peer churn and in-network adversaries can be best alleviated through balanced redundant coverage, and frequent reshuffling of the peering links.","s":"Summary","u":"/rlog/GossipSub Improvements","h":"#summary","p":303},{"i":322,"t":"[1] D. Vyzovitis, Y. Napora, D. McCormick, D. Dias, and Y. Psaras, “Gossipsub: Attack-resilient message propagation in the filecoin and eth2. 0 networks,” arXiv preprint arXiv:2007.02754, 2020. Retrieved from https://arxiv.org/pdf/2007.02754.pdf [2] M. Matos, V. Schiavoni, P. Felber, R. Oliveira, and E. Riviere, “Brisa: Combining efficiency and reliability in epidemic data dissemination,” in 2012 IEEE 26th International Parallel and Distributed Processing Symposium. IEEE, 2012, pp. 983–994. Retrieved from https://ieeexplore.ieee.org/abstract/document/6267905 [3] P. T. Eugster, R. Guerraoui, A. M. Kermarrec, and L. Massouli, “Epidemic information dissemination in distributed systems,” IEEE Computer, vol. 37, no. 5, 2004. Retrieved from https://infoscience.epfl.ch/record/83478/files/EugGueKerMas04IEEEComp.pdf [4] D. Frey, “Epidemic protocols: From large scale to big data,” Ph.D. dissertation, Universite De Rennes 1, 2019. Retrieved from https://inria.hal.science/tel-02375909/document [5] M. Jain and C. Dovrolis, “End-to-end available bandwidth: measurement methodology, dynamics, and relation with tcp throughput,” IEEE/ACM Transactions on networking, vol. 11, no. 4, pp. 537–549, 2003. Retrieved from https://ieeexplore.ieee.org/abstract/document/1224454 [6] R. Prasad, C. Dovrolis, M. Murray, and K. Claffy, “Bandwidth estimation: metrics, measurement techniques, and tools,” IEEE network, vol. 17, no. 6, pp. 27–35, 2003. Retrieved from https://ieeexplore.ieee.org/abstract/document/1248658 [7] D. Kostic, A. Rodriguez, J. Albrecht, and A. Vahdat, “Bullet: High bandwidth data dissemination using an overlay mesh,” in Proceedings of the nineteenth ACM symposium on Operating systems principles, 2003, pp. 282–297. Retrieved from https://dl.acm.org/doi/abs/10.1145/945445.945473 [8] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, and A. E. Mohr, “Chainsaw: Eliminating trees from overlay multicast,” in Peer-to-Peer Systems IV: 4th International Workshop, IPTPS 2005, Ithaca, NY, USA, February 24-25, 2005. Revised Selected Papers 4. Springer, 2005, pp. 127–140. Retrieved from https://link.springer.com/chapter/10.1007/11558989_12 [9] Y.-D. Bromberg, Q. Dufour, and D. Frey, “Multisource rumor spreading with network coding,” in IEEE INFOCOM 2019-IEEE Conference on Computer Communications. IEEE, 2019, pp. 2359–2367. Retrieved from https://ieeexplore.ieee.org/abstract/document/8737576 [10] B. Haeupler, “Analyzing network coding gossip made easy,” in Proceedings of the forty-third annual ACM symposium on Theory of computing, 2011, pp. 293–302. Retrieved from https://dl.acm.org/doi/abs/10.1145/1993636.1993676 [11] S. Yu and Z. Li, “Massive data delivery in unstructured peer-to-peer networks with network coding,” in 6th IEEE/ACIS International Conference on Computer and Information Science (ICIS 2007). IEEE, 2007, pp. 592–597. Retrieved from https://ieeexplore.ieee.org/abstract/document/4276446 [12] V. Buterin, D. Feist, D. Loerakker, G. Kadianakis, M. Garnett, M. Taiwo, and A. Dietrichs, “Eip-4844: Shard blob transactions scale data-availability of ethereum in a simple, forwards-compatible manner,” 2022. Retrieved from https://eips.ethereum.org/EIPS/eip-4844 [13] A. Manning, “Gossipsub extension for epidemic meshes (v1.2.0),” 2022. Retrieved from https://github.com/libp2p/specs/pull/413 [14] Z. Duan, C. Tian, M. Zhou, X. Wang, N. Zhang, H. Du, and L. Wang, “Two-layer hybrid peer-to-peer networks,” Peer-to-Peer Networking and Applications, vol. 10, pp. 1304–1322, 2017. Retrieved from https://link.springer.com/article/10.1007/s12083-016-0460-5 [15] W. Hao, J. Zeng, X. Dai, J. Xiao, Q. Hua, H. Chen, K.-C. Li, and H. Jin, “Blockp2p: Enabling fast blockchain broadcast with scalable peer-to-peer network topology,” in Green, Pervasive, and Cloud Computing: 14th International Conference, GPC 2019, Uberlandia, Brazil, May 26–28, 2019, Proceedings 14. Springer, 2019, pp. 223–237. Retrieved from https://link.springer.com/chapter/10.1007/978-3-030-19223-5_16 [16] H. Qiu, T. Ji, S. Zhao, X. Chen, J. Qi, H. Cui, and S. Wang, “A geography-based p2p overlay network for fast and robust blockchain systems,” IEEE Transactions on Services Computing, 2022. Retrieved from https://ieeexplore.ieee.org/abstract/document/9826458","s":"References","u":"/rlog/GossipSub Improvements","h":"","p":303},{"i":324,"t":"This post provides quick insights into the IDONTWANT message performance and highlights minor tweaks that can further contribute to performance gains.","s":"Libp2p GossipSub IDONTWANT Message Performance Impact","u":"/rlog/gsub-idontwant-perf-eval","h":"","p":323},{"i":326,"t":"IDONTWANT messages are introduced to curtail redundant transmissions without compromising resilience. Cutting down on duplicates can potentially render two significant advantages: Reducing bandwidth requirements Reducing message dissemination time (latency) For IDONTWANTs to be effective, they must be received and processed by the sender before the sender starts relaying the respective message. Duplicates investigation reveals that the average time difference between the first message arrival and the first duplicate arrival is higher than the average round trip time in Ethereum's GossipSub network. This allows for timely IDONTWANT reception and canceling of many duplicate transmissions, showing a potential for a significant drop in bandwidth utilization. On the other hand, lowering message dissemination time is only possible by minimizing queuing delays at busy peers.","s":"Overview","u":"/rlog/gsub-idontwant-perf-eval","h":"#overview","p":323},{"i":328,"t":"We conducted a series of experiments with different arrangements (changing heartbeat_interval and message size) to precisely identify the impact of IDONTWANT messages on bandwidth utilization and message dissemination time. The experiments are performed on nim-libp2p using the shadow simulator. The peer bandwidth and link latency are uniformly set between 50-150 Mbps and 40-130 milliseconds in five stages. In all experiments, ten messages are transmitted to the network, i.e., ten peers (publishers) are selected as the message transmitters. Every publisher transmits exactly one message, and inter-packet spacing (delay) is set to four seconds for each published message. For a fair assessment, we ensure that the publishers are uniformly selected from each bandwidth class. At the start of each experiment, two additional messages are transmitted to increase the TCP CwndC_{wnd}Cwnd​. These messages are not included in latency computations. The simulation details are presented in the table below. Parameter Value Parameter Value Peers 2000 Publishers 10 Peer bandwidth 50-150 Mbps Link latency 40-130 ms Message size 1KB, 50KB, 500KB, 1MB DDD 8 Heartbeat interval 700ms, 1000ms, 1500ms DlowD_{low}Dlow​ 6 FloodPublish False DhighD_{high}Dhigh​ 12 Gossip factor 0.05 Muxer yamux","s":"Experiments","u":"/rlog/gsub-idontwant-perf-eval","h":"#experiments","p":323},{"i":330,"t":"We use bandwidth utilization and latency as evaluation metrics. Bandwidth utilization represents total network-wide traffic (including gossip and other control messages). Latency refers to network-wide message dissemination time. The total number of IWANT requests and the number of message transmissions saved by IDONTWANT messages are also presented for detailed insights. Experiments reveal that IDONTWANT messages yield a noticeable (up to 21%) drop in bandwidth utilization. A higher drop is seen with a higher heartbeat interval. Interestingly, a relatively low bandwidth reduction (12-20%) is seen for 1MB messages, compared to 500KB messages (18-21%). This is because downloading a large message may consume several hundred milliseconds. During this time, a receiver will likely generate multiple IWANT requests for the same message, increasing bandwidth utilization. Moreover, a peer can generate IDONTWANTs only after it has finished downloading the message. A longer download time will result in simultaneous reception of the same message from other mesh members. These IWANT requests mainly overwhelm early message receivers, which can negatively impact message dissemination time on some occasions. Therefore, a similar message dissemination time is seen with and without IDONTWANT messages. Similar results are seen on our large-scale deployment runs (running Waku nodes in Kubernetes). Please feel free to join the discussion and leave feedback regarding this post in the VAC forum.","s":"Findings","u":"/rlog/gsub-idontwant-perf-eval","h":"#findings","p":323},{"i":332,"t":"GossipSub Specifications v1.2 GossipSub v1.2: IDONTWANT Control Message Number Duplicate Messages in Ethereum’s Gossipsub Network IWANT Messages Impact on Latency Large Message Handling (IDONTWANT + IMReceiving) IDONTWANT Message Impact Before/After Message Validation GossipSub for Big Messages Regression Test Results: nim-libp2p","s":"References","u":"/rlog/gsub-idontwant-perf-eval","h":"#references","p":323},{"i":334,"t":"Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.","s":"Introducing nwaku","u":"/rlog/introducing-nwaku","h":"","p":333},{"i":336,"t":"If you've been following our research log, you'll know that many things have happened in the world of Waku v2 since our last general update. In line with our long term goals, we've introduced new protocols, tweaked our existing protocols and expanded our team. We've also shown in a series of practical experiments that Waku v2 does indeed deliver on some of the theoretical advantages it was designed to have over its predecessor, Waku v1. A sustainability and business workshop led to the formulation of a clearer vision for Vac as a team. From the beginning, our protocol development has been complemented by various client implementations of these protocols, first in Nim, but later also in JavaScript and Go. A follow-up post will clarify the purposes, similarities and differences between these three clients. The Nim client, is our reference implementation, developed by the research team in parallel with the specs and building on a home-grown implementation of libp2p. The Nim client is suitable to run as a standalone adaptive node, managed by individual operators or as an encapsulated service node in other applications. This post looks at some recent developments within the Nim client.","s":"Background","u":"/rlog/introducing-nwaku","h":"#background","p":333},{"i":338,"t":"Pronounced NWHA-koo. You may already have seen us refer to \"nwaku\" on Vac communication channels, but it is now official: The nim-waku Waku v2 client has been named nwaku. Why? Well, we needed a recognizable name for our client that could easily be referred to in everyday conversations and nim-waku just didn't roll off the tongue. We've followed the example of the closely related nimbus project to find a punchier name that explicitly links the client to both the Waku set of protocols and the Nim language.","s":"1. nim-waku is now known as nwaku","u":"/rlog/introducing-nwaku","h":"#1-nim-waku-is-now-known-as-nwaku","p":333},{"i":340,"t":"The initial implementation of Waku v2 demonstrated how the suite of protocols can be applied to form a generalized, peer-to-peer messaging network, while addressing a wide range of adaptive requirements. This allowed us to lift several protocol specifications from raw to draft status, indicating that a reference implementation exists for each. However, as internal dogfooding increased and more external applications started using nwaku, we stepped up our focus on the client's stability and performance. This is especially true where we want nwaku to run unsupervised in a production environment without any degradation in the services it provides. Some of the more significant productionization efforts over the last couple of months included: Reworking the store implementation to maintain stable memory usage while storing historical messages and serving multiple clients querying history simultaneously. Previously, a store node would see gradual service degradation due to inefficient memory usage when responding to history queries. Queries that often took longer than 8 mins now complete in under 100 ms. Improved peer management. For example, filter nodes will now remove unreachable clients after a number of connection failures, whereas they would previously keep accumulating dead peers. Improved disk usage. nwaku nodes that persist historical messages on disk now manage their own storage size based on the --store-capacity. This can significantly improve node start-up times. More stability issues may be addressed in future as nwaku matures, but we've noticed a marked improvement in the reliability of running nwaku nodes. These include environments where nwaku nodes are expected to run with a long uptime. Vac currently operates two long-running fleets of nwaku nodes, wakuv2.prod and wakuv2.test, for internal dogfooding and to serve as experimental bootstrapping nodes. Status has also recently deployed similar fleets for production and testing based on nwaku. Our goal is to have nwaku be stable, performant and flexible enough to be an attractive option for operators to run and maintain their own Waku v2 nodes. See also the future work section below for more on our general goal of nwaku for operators.","s":"2. Improvements in stability and performance","u":"/rlog/introducing-nwaku","h":"#2-improvements-in-stability-and-performance","p":333},{"i":342,"t":"We've implemented several features that improve nwaku's usability in different environments and its interoperability with other Waku v2 clients. One major step forward here was adding support for both secure and unsecured WebSocket connections as libp2p transports. This allows direct connectivity with js-waku and paves the way for native browser usage. We've also added support for parsing and resolving DNS-type multiaddrs, i.e. multiaddress protocol schemes dns, dns4, dns6 and dnsaddr. A nwaku node can now also be configured with its own IPv4 DNS domain name allowing dynamic IP address allocation without impacting a node's reachability by its peers.","s":"3. Improvements in interoperability","u":"/rlog/introducing-nwaku","h":"#3-improvements-in-interoperability","p":333},{"i":344,"t":"Peer discovery is the method by which nodes become aware of each other’s existence. The question of peer discovery in a Waku v2 network has been a focus area since the protocol was first conceptualized. Since then several different approaches to discovery have been proposed and investigated. We've implemented three discovery mechanisms in nwaku so far:","s":"4. Peer discovery","u":"/rlog/introducing-nwaku","h":"#4-peer-discovery","p":333},{"i":346,"t":"nwaku nodes can retrieve an authenticated, updateable list of peers via DNS to bootstrap connection to a Waku v2 network. Our implementation is based on EIP-1459.","s":"DNS-based discovery","u":"/rlog/introducing-nwaku","h":"#dns-based-discovery","p":333},{"i":348,"t":"GossipSub Peer Exchange (PX) is a GossipSub v1.1 mechanism whereby a pruning peer may provide a pruned peer with a set of alternative peers where it can connect to reform its mesh. This is a very suitable mechanism to gradually discover more peers from an initial connection to a small set of bootstrap peers. It is enabled in a nwaku node by default.","s":"GossipSub peer exchange","u":"/rlog/introducing-nwaku","h":"#gossipsub-peer-exchange","p":333},{"i":350,"t":"This is a DHT-based discovery mechanism adapted to store and relay node records. Our implementation is based on Ethereum's Discovery v5 protocol with some minor modifications to isolate our discovery network from that of Ethereum. The decision to separate the Waku Discovery v5 network from Ethereum's was made on considerations of lookup efficiency. This comes at a possible tradeoff in network resilience. We are considering merging with the Ethereum Discovery v5 network in future, or even implement a hybrid solution. This post explains the decision and future steps.","s":"Waku Node Discovery Protocol v5","u":"/rlog/introducing-nwaku","h":"#waku-node-discovery-protocol-v5","p":333},{"i":352,"t":"An early addition to our suite of protocols was an extension of 11/WAKU-RELAY that provided spam protection using Rate Limiting Nullifiers (RLN). The nwaku client now contains a working demonstration and integration of RLN relay. Check out this tutorial to see the protocol in action using a toy chat application built on nwaku. We'd love for people to join us in dogfooding RLN spam protection as part of our operator incentive testnet. Feel free to join our Vac Discord server and head to the #rln channel for more information.","s":"5. Spam protection using RLN","u":"/rlog/introducing-nwaku","h":"#5-spam-protection-using-rln","p":333},{"i":354,"t":"As we continue working towards our goal of a fully decentralized, generalized and censorship-resistant messaging protocol, these are some of the current and future focus areas for nwaku:","s":"Future work","u":"/rlog/introducing-nwaku","h":"#future-work","p":333},{"i":356,"t":"We are starting to push for operators to run and maintain their own Waku v2 nodes, preferably contributing to the default Waku v2 network as described by the default pubsub topic (/waku/2/default-waku/proto). Amongst other things, a large fleet of stable operator-run Waku v2 nodes will help secure the network, provide valuable services to a variety of applications and ensure the future sustainability of both Vac as a research organization and the Waku suite of protocols. We are targeting nwaku as the main option for operator-run nodes. Specifically, we aim to provide through nwaku: a lightweight and robust Waku v2 client. This client must be first in line to support innovative and new Waku v2 protocols, but configurable enough to serve the adaptive needs of various operators. an easy-to-follow guide for operators to configure, set up and maintain their own nodes a set of operator-focused tools to monitor and maintain a running node","s":"Reaching out to operators:","u":"/rlog/introducing-nwaku","h":"#reaching-out-to-operators","p":333},{"i":358,"t":"Conversational security guarantees in Waku v2 are currently designed around the Status application. Developers building their own applications on top of Waku would therefore either have to reimplement a set of tools similar to Status or build their own security solutions on the application layer above Waku. We are working on a set of features built into Waku that will provide the general security properties Waku users may desire and do so in a modern and simple way. This is useful for applications outside of Status that want similar security guarantees. As a first step, we've already made good progress toward integrating noise handshakes as a key exchange mechanism in Waku v2.","s":"Better conversational security layer guarantees","u":"/rlog/introducing-nwaku","h":"#better-conversational-security-layer-guarantees","p":333},{"i":360,"t":"We want to design incentivization around our protocols to encourage desired behaviors in the Waku network, rewarding nodes providing costly services and punishing adversarial actions. This will increase the overall security of the network and encourage operators to run their own Waku nodes. In turn, the sustainability of Vac as an organization will be better guaranteed. As such, protocol incentivization was a major focus in our recent Vac Sustainability and Business Workshop. Our first step here is to finish integrating RLN relay into Waku with blockchain interaction to manage members, punish spammers and reward spam detectors. After this, we want to design monetary incentivization for providers of store, lightpush and filter services. This may also tie into a reputation mechanism for service nodes based on a network-wide consensus on service quality. A big challenge for protocol incentivization is doing it in a private fashion, so we can keep similar metadata protection guarantees as the Waku base layer. This ties into our focus on Zero Knowledge tech.","s":"Protocol incentivization","u":"/rlog/introducing-nwaku","h":"#protocol-incentivization","p":333},{"i":362,"t":"The nwaku store currently serves as an efficient in-memory store for historical messages, dimensioned by the maximum number of messages the store node is willing to keep. This makes the nwaku store appropriate for keeping history over a short term without any time-based guarantees, but with the advantage of providing fast responses to history queries. Some applications, such as Status, require longer-term historical message storage with time-based dimensioning to guarantee that messages will be stored for a specified minimum period. Because of the relatively high cost of memory compared to disk space, a higher capacity store, with time guarantees, should operate as a disk-only database of historical messages. This is an ongoing effort.","s":"Improved store capacity","u":"/rlog/introducing-nwaku","h":"#improved-store-capacity","p":333},{"i":364,"t":"In addition to the three discovery methods already implemented in nwaku, we are working on improving discovery on at least three fronts: Capability discovery:​ Waku v2 nodes may be interested in peers with specific capabilities, for example: peers within a specific pubsub topic mesh, peers with store capability, store peers with x days of history for a specific content topic, etc. Capability discovery entails mechanisms by which such capabilities can be advertised and discovered/negotiated. One major hurdle to overcome is the increased complexity of finding a node with specific capabilities within the larger network (a needle in a haystack). See the original problem statement for more. Improvements in Discovery v5​ Of the implemented discovery methods, Discovery v5 best addresses our need for a decentralized and scalable discovery mechanism. With the basic implementation done, there are some improvements planned for Discovery v5, including methods to increase security such as merging with the Ethereum Discovery v5 network, introducing explicit NAT traversal and utilizing topic advertisement. The Waku v2 Discovery v5 Roadmap contains more details. Generalized peer exchange​ nwaku already implements GossipSub peer exchange. We now need a general request-response mechanism outside of GossipSub by which a node may learn about other Waku v2 nodes by requesting and receiving a list of peers from a neighbor. This could, for example, be a suitable way for resource-restricted devices to request a stronger peer to perform a random Discovery v5 lookup on their behalf or simply to be informed of a subset of the peers known to that neighbor. See this issue for more. This concludes a general outline of some of the main recent developments in the nwaku client and a summary of the current and future focus areas. Much more is happening behind the scenes, of course, so for more information, or to join the conversation, feel free to join our Vac Discord server or to check out the nwaku repo on Github. You can also view the changelog for past releases here.","s":"Multipurpose discovery","u":"/rlog/introducing-nwaku","h":"#multipurpose-discovery","p":333},{"i":366,"t":"17/WAKU-RLN-RELAY 32/RLN 33/WAKU2-DISCV5 Capabilities advertising Configuring a domain name Conversational security Discovery v5 Topic Advertisement EIP-1459 GossipSub Peer Exchange go-waku js-waku multiaddr formats nimbus-eth2 nim-libp2p nim-waku nim-waku releases Node Discovery Protocol v5 - Theory Noise handshakes RLN tutorial Vac <3 ZK Vac About page Vac Research log Vac RFC site Vac Sustainability and Business Workshop Waku Update Waku v1 vs Waku v2: Bandwidth Comparison Waku v2 Peer Exchange Waku v2 Discovery v5 Roadmap What's the Plan for Waku v2?","s":"References","u":"/rlog/introducing-nwaku","h":"#references","p":333},{"i":368,"t":"Large Message Handling in GossipSub: Potential Improvements","s":"Large Message Handling in GossipSub: Potential Improvements","u":"/rlog/gsub-largemsg-improvements","h":"","p":367},{"i":370,"t":"The challenge of large message transmissions in GossipSub leads to longer than expected network-wide message dissemination times (and relatively higher fluctuations). It is particularly relevant for applications that require on-time, network-wide dissemination of large messages, such as Ethereum and Waku [1,2]. This matter has been extensively discussed in the libp2p community [3, 4, 5, 6, 7, 8], and numerous improvements have been considered (or even incorporated) for the GossipSub protocol to enable efficient large-message propagation [3, 7, 9, 10].","s":"Motivation","u":"/rlog/gsub-largemsg-improvements","h":"#motivation","p":367},{"i":372,"t":"Sending a message to N peers involves approximately ⌈log⁡D(N)⌉\\lceil \\log_D(N) \\rceil⌈logD​(N)⌉ rounds, with approximately (D−1)X−1×D(D-1)^{X-1} \\times D(D−1)X−1×D transmissions in each round, where X,DX, DX,D represent the round number and mesh size. Transmitting to a higher number of peers (floodpublish) can theoretically reduce latency by increasing the transmissions in each round to (D−1)X−1×(F+D)(D-1)^{X-1} \\times (F+D)(D−1)X−1×(F+D), where FFF represents the number of peers included in floodpublish. This arrangement works fine for relatively small/moderate message sizes. However, as message sizes increase, significant rises and fluctuations in network-wide message dissemination time are seen. Interestingly, a higher DDD or FFF can also degrade performance in this situation. Several aspects contribute to this behavior: Ideally, a message transmission to a single peer concludes in τ1=LR+P\\tau_1 = \\frac {L}{R}+Pτ1​=RL​+P (ignoring any message processing time), where L,R,PL, R, PL,R,P represent message size, data rate, and link latency. Therefore, the time required for sending a message on a 100Mbps link with 100ms latency jumps from τ110KB=100.8ms\\tau_1^{10KB} = 100.8msτ110KB​=100.8ms for a 10KB message to τ11MB=180ms\\tau_1^{1MB} = 180msτ11MB​=180ms for a 1MB message. For DDD peers, the transmission time increases to τD1MB=(80×D)+100ms\\tau_D^{1MB} = (80 \\times D) + 100msτD1MB​=(80×D)+100ms, triggering additional queuing delays (proportional to the transmission queue size) during each transmission round. In practice, τ11MB\\tau_1^{1MB}τ11MB​ sometimes rises to several hundred milliseconds, further exaggerating the abovementioned queuing delays. This rise is because TCP congestion avoidance algorithms usually limit maximum in-flight bytes in a round trip time (RTT) based on the congestion window (CwndC_{wnd}Cwnd​) and maximum segment size (MSS) to approximately Cwnd×MSS{C_{wnd} \\times MSS}Cwnd​×MSS, with CwndC_{wnd}Cwnd​ rising with the data transfer for each flow. Consequently, sending the same message through a newly established (cold) connection takes longer. The message transfer time lowers as the CwndC_{wnd}Cwnd​ grows. Therefore, performance-improvement practices such as floodpublish, frequent mesh adjustment, and lazy sending typically result in longer than expected message dissemination times for large messages (due to cold connections). It is also worth mentioning that some TCP variants reset their CwndC_{wnd}Cwnd​ after different periods of inactivity. Theoretically, the message transmission time to D peers (τD)(\\tau_D)(τD​) remains the same even if the message is relayed sequentially to all peers or simultaneous transmissions are carried out, i.e., τD=∑i=1Dτi\\tau_D = \\sum_{i=1}^{D} \\tau_iτD​=∑i=1D​τi​ However, sequential transmissions finish early for individual peers, allowing them to relay early. This may result in quicker network-wide message dissemination. A realistic network comprises nodes with dissimilar capabilities (bandwidth, link latency, compute, etc.). As the message disseminates, it's not uncommon for some peers to receive it much earlier than others. Early gossip (IHAVE announcements) may bring in many IWANT requests to the early receivers (even from peers already receiving the same message), which adds to their workload. A busy peer (with a sizeable outgoing message queue) will enqueue (or simultaneously transfer) newly scheduled outgoing messages. As a result, already scheduled messages are prioritized over those published by the peer itself, introducing a significant initial delay to the locally published messages. Enqueuing IWANT replies to the outgoing message queue can further exaggerate the problem. The lack of adaptiveness and standardization in outgoing message prioritization are key factors that can lead to noticeable inconsistency in message dissemination latency at each hop, even in similar network conditions. Message size directly contributes to peers' workloads in terms of processing and transmission time. It also raises the probability of simultaneous redundant transmissions to the same peer, resulting in bandwidth wastage, congestion, and slow message propagation to the network. Moreover, the benefits of sequential message relaying can be compromised by prioritizing slow (or busy) peers. Most use cases necessitate validating received messages before forwarding them to the next-hop peers. For a higher message transfer time (τ)(\\tau )(τ), this store-and-forward delay accumulates across the hops traveled by the message.","s":"Problem description","u":"/rlog/gsub-largemsg-improvements","h":"#problem-description","p":367},{"i":375,"t":"The impact of message size and achievable data rate on message transmit time τ\\tauτ is crucial as this time accumulates due to the store-and-forward delay introduced at intermediate hops. Some possible improvements to minimize overall message dissemination latency include: a. Message fragmentation​ In a homogeneous network, network-wide message dissemination time (ignoring any processing delays) can be simplified to roughly δ≈δTx+Ph\\delta \\approx \\delta_{Tx} + P_hδ≈δTx​+Ph​, where δTx\\delta_{Tx}δTx​ represents accumulative message transmit time denoted as δTx=SR×h\\delta_{Tx} = \\frac{S}{R} \\times hδTx​=RS​×h, with S,RS, RS,R being the data size and data rate, and h,Phh, P_hh,Ph​ being the number of hops in the longest path and message propagation time through the longest path. Partitioning a large message into n fragments reduces a single fragment transmit time to δTxn\\frac{\\delta_{Tx}}{n}nδTx​​. As a received fragment can be immediately relayed by the receiver (while the sender is still transmitting the remaining fragments), it reduces the transmit time to δTx=SR×2h−1n\\delta_{Tx} = \\frac{S}{R} \\times \\frac{2h-1}{n}δTx​=RS​×n2h−1​. This time reduction is mainly attributed to the smaller store-and-forward delay involved in fragment transmissions. However, it is worth noting that many applications require each fragment to be individually verifiable. At the same time, message fragmentation allows a malicious peer to never relay some fragments of a message, which can lead to a significant rise in the application's receive buffer size. Therefore, message fragmentation requires a careful tradeoff analysis between time and risks. b. Message staggering​ Considering the same bandwidth, the time τD\\tau_DτD​ required for sending a message to D peers stays the same, even if we relay to all peers in parallel or send sequentially to the peers, i.e., τD=∑i=1Dτi\\tau_D = \\sum_{i=1}^{D} \\tau_iτD​=∑i=1D​τi​. However, sequential relaying results in quicker message reception at individual peers (τ1≈τDD\\tau_1 \\approx \\frac{\\tau_D}{D}τ1​≈DτD​​) due to bandwidth concentration for a particular peer. So, the receiver can start relaying early to its mesh members while the original sender is still sending the message to other peers. As a result, after every τDD\\frac{\\tau_D}{D}DτD​​ milliseconds, the number of peers receiving the message increases by 2X ∀ X∈{0,D−1}2^X\\ \\forall\\ X \\in \\{0, D-1\\}2X ∀ X∈{0,D−1} and by ∑k=X−DX−1λk ∀ X≥D\\sum_{k=X-D}^{X-1} \\lambda_k\\ \\forall\\ X \\geq D∑k=X−DX−1​λk​ ∀ X≥D. Here, XXX represents message transmission round X=i⋅τDD∣i∈N0X = i \\cdot \\frac{\\tau_D}{D} \\mid i \\in \\mathbb{N}_0X=i⋅DτD​​∣i∈N0​, and λk\\lambda_kλk​ represents the number of peers that received the message in round kkk. It is worth noting that a realistic network imposes certain constraints on staggering for peers. For instance, in a network with dissimilar peer capabilities, placing a slow peer (also in cases where many senders simultaneously select the same peer) at the head of the transmission queue may result in head-of-line blocking for the message queue. At the same time, early receivers get many IWANT requests, increasing their workload. c. Message prioritization for slow senders​ A slow peer often struggles with a backlog of messages in the outgoing message queue(s) for mesh members. Any new message transmission at this stage (especially the locally published messages) gets delayed. Adaptive message-forwarding can help such peers prioritize traffic to minimize latency for essential message transfers. For instance, any GossipSub peer will likely receive every message from multiple senders, leading to redundant transmissions [11]. Implementing efficient strategies (only for slow senders) like lazy sending and prioritizing locally published messages/IWANT replies over already queued messages can help minimize outgoing message queue sizes and optimize bandwidth for essential message transfers. A peer can identify itself as a slow peer by using any bandwidth estimation approach or simply setting an outgoing message queue threshold for all mesh members. Eliminating/deprioritizing some messages can lower a peer's score, but it also earns the peer an overall better score by achieving some early message transfers. For instance, sending many near-first messages can only save a peer from a deficit penalty. On the other hand, sending only one message (assuming MeshMessageDeliveriesThreshold defaults to 1) as the first delivered message can add to the accumulative peer score.","s":"1. Minimizing transfer time for large messages","u":"/rlog/gsub-largemsg-improvements","h":"#1-minimizing-transfer-time-for-large-messages","p":367},{"i":377,"t":"Congestion avoidance algorithms used in various TCP versions directly influence achievable throughput and message transfer time as maximum unacknowledged in-flight bytes are based on the congestion window (Cwnd)(C_{wnd})(Cwnd​) size. Rapid adaptation of CwndC_{wnd}Cwnd​ to the available network conditions can help lower message dissemination latency. Therefore, selecting a more suitable TCP variant like BBR, which is known for its ability to dynamically adjust the congestion window based on network conditions, can significantly enhance GossipSub's performance. At the same time, parameters like receive window scaling and initial CwndC_{wnd}Cwnd​ also impact message transfer time, but these are usually OS-specific system-wide choices. One possible solution is to raise CwndC_{wnd}Cwnd​ by exchanging data over the newly established connection. This data may involve useful details like peer exchange information and gossip to build initial trust, or GossipSub can use some dummy data to raise CwndC_{wnd}Cwnd​ to a reasonable level. It's important to understand that some TCP variants reset CwndC_{wnd}Cwnd​ after specific periods of inactivity [12]. This can lead to a decline in TCP's performance for applications that generate traffic after intervals long enough to trigger the resetting of the congestion window. Implementing straightforward measures like transport-level ping-pong messages can effectively mitigate this problem [13]. The limitations faced with CwndC_{wnd}Cwnd​ scaling also impact some performance optimizations in GossipSub. For instance, floodpublishing is an optimization relying on additional transmissions by the publisher to minimize message dissemination latency. However, a small CwndC_{wnd}Cwnd​ value in (new/cold) TCP connections established with floodpublish peers significantly increases message transmission time [4]. Usually, these peers also receive the same message from other sources during this time, wasting the publisher's bandwidth. The same is the case with IWANT replies. Maintaining a bigger mesh (with warm TCP connections) and relaying to DDD peers can be a better alternative to this problem.","s":"2. Mitigating transport issues","u":"/rlog/gsub-largemsg-improvements","h":"#2-mitigating-transport-issues","p":367},{"i":379,"t":"For every received packet, a peer makes roughly DDD transmissions to contribute its fair share to the spread of messages. However, the fact that many recipients had already received the message (from some other peer) makes this message propagation inefficient. Although the DDD-spread is attributed to quicker dissemination and resilience against non-conforming peers, many potential solutions can still minimize redundant transmissions while preserving the resilience of GossipSub. These solutions, ranging from probabilistic to more knowledgeful elimination of messages from the outgoing message queue, not only address the issue of redundancy but also provide an opportunity for bandwidth optimization, especially for resource-constrained peers. For instance, an IDONTWANT message, a key component of GossipSub (v1.2) [10], can significantly reduce redundant transmissions. It allows any node to notify its mesh members that it has already received a message, thereby preventing them from resending the same message. This functionality is useful when a node receives a message larger than a specified threshold. In such cases, the node promptly informs its mesh peers about the successful reception of the message by sending IDONTWANT messages. It's important to note that an IDONTWANT message is essentially an IHAVE message, but with a crucial difference, i.e., IHAVEs are only transmitted during the heartbeat intervals, whereas IDONTWANTs are sent immediately after receiving a large message. This prompt notification helps curtail redundant large message transmissions without compromising the GossipSub resilience. However, the use of IDONTWANT messages alone has an inherent limitation. For instance, a peer can only send an IDONTWANT after receiving the complete message. A large message transmission consumes significant time. For example, transmitting a 1MB message at 100 Mbps bandwidth may consume 80 to several hundred milliseconds (depending upon CwndC_{wnd}Cwnd​ and latency). As a result, other mesh members may also start transmitting the same message during this interval. A few potential solutions include: a. Staggering with IDONTWANT messages​ As previously discussed, staggering can significantly reduce network-wide message dissemination latency. This is primarily due to the relatively smaller store-and-forward delays that are inherent in this approach. Using both staggering and IDONTWANT messages can further enhance efficiency by reducing redundant transmissions. This is because a node only saturates its bandwidth for a small subset of mesh peers, leading to early transmissions and prompt IDONTWANT message notifications to the mesh members. It is worth highlighting that staggering can be implemented in various ways. For example, it can be applied to peers (peer staggering) where a node sequentially relays the same message to all peers one by one. Alternatively, a node can send a different message to every peer (message staggering or rotational sending), allowing IDONTWANTs for other messages to arrive during this time. The message staggering approach is beneficial when several messages are introduced to the network within a short interval of time. As the peers in staggered sending are sequentially covered (with a faster speed due to bandwidth concentration), this leads to another problem. The early covered peers send IHAVE (during their heartbeat intervals) for the messages they have received. IHAVE announcements for newly received large messages trigger IWANTs from nodes (including those already receiving the same message), leading to an additional workload for early receivers [14]. Potential solutions to mitigate these problems include: Defering IHAVE announcements for large messages. Deferring IHAVE announcements can indirectly prioritize message transmission to the mesh peers over IWANT replies. However, deciding on a suitable deferred interval is crucial for optimal performance. One possible solution is to generate IHAVEs only after the message is relayed to all the mesh peers. Defering IWANT requests for messages that are currently being received. This requires prior knowledge of msgIDs for the messages under reception. Knowing the message length is also essential in deciding a suitable defer interval to handle situations where a sender starts sending a message and never completes the transmission. Not issuing IWANT for a message if at least KKK peers have transmitted IDONTWANT for the same message (as this indicates that these peers will eventually relay this message). However, this approach can inadvertently empower a group of non-conforming mesh peers to send IDONTWANT for a message and never complete message transmission. A delayed IWANT, along with negative peer scoring, can remedy this problem. b. IMReceiving message​ A peer can issue an IDONTWANT only after it has received the entire message. However, a large message transmission may take several hundred milliseconds to complete. During this time, many other mesh members may start relaying the same message. Therefore, the probability of simultaneously receiving the same message from multiple senders increases with the message size, significantly compromising the effectiveness of IDONTWANT messages. Sending a short preamble (containing msgID and length) before the message transmission can provide valuable information about the message. If a receiver is already receiving the same message from another sender, the receiver can request to defer this transmission by sending a brief IMReceiving message. An IDONTWANT from the receiver will indicate successful message reception. Otherwise, the waiting sender can initiate transmission after a specific wait interval. However, waiting for IMReceiving after sending the preamble can delay the message transmission. On the other hand, proceeding with message transfer (after sending the preamble) leads to another problem: it is difficult to cancel ongoing message transmission after receiving IMReceiving for the same message. To streamline this process, a peer can immediately send an IMReceiving message (for every received preamble), urging other mesh peers to defer sending the same message [15, 16]. The other peers can send this message if IDONTWANT is not received from the receiver during the wait interval. This approach can boost IDONTWANT benefits by considering ongoing transmissions for large messages. While IMReceiving messages can bring about substantial improvements in terms of latency and bandwidth utilization, it's crucial to be aware of the potential risks. A malicious user can exploit this approach to disrupt message transmission either by never completing a message or by intentionally sending a message at an extremely slow rate to numerous peers. This could ultimately result in network-wide slow message propagation. However, carefully calibrating the deferring interval (based on message size) and negative peer scoring can help mitigate these risks. c. IDONTWANT message with reduced forwarding​ It is common for slow peers to pile up outgoing message queues, especially for large message transfers. This results in a significant queuing delay for outgoing messages. Reduced message forwarding can help decrease the workload of slower peers. On receiving a message longer than the specified threshold, a slow peer can relay it to only K∈DK \\in DK∈D peers and send an IDONTWANT message to all the peers in DDD. In this arrangement, the IDONTWANT message serves an additional purpose: to promptly announce data availability, reinforcing redundancy in the presence of adversaries. When a peer receives an IDONTWANT for an unseen message, it learns about the new message and can request it by sending an IWANT request without waiting for the heartbeat (gossip) interval. As a result, a significantly smaller number of transmissions is sufficient for propagating the message to the entire network. This approach conserves peer bandwidth by minimizing redundant transmissions while ensuring GossipSub resilience at the cost of one RTT (for missing peers). Interestingly, curtailing queuing delays can also help lower network-wide message dissemination latency (for huge messages). However, finding an appropriate value for KKK is crucial for optimal performance. A smaller KKK saves peer bandwidth, while a larger KKK achieves quicker spread until outgoing message queues pile up. Setting K=DlowK = D_{low}K=Dlow​ can be one option. It is worth mentioning that such behavior may negatively impact peer scoring (by missing message delivery rewards from D−KD-KD−K peers). However, a minimized workload enables early message dissemination to the remaining peers. These early transmissions and randomized KKK set selection can help achieve an overall better peer score.","s":"3. Eliminating redundant transmissions","u":"/rlog/gsub-largemsg-improvements","h":"#3-eliminating-redundant-transmissions","p":367},{"i":381,"t":"Despite the standardized specifications of the GossipSub protocol, the message forwarding mechanisms can significantly impact network-wide message dissemination latency and bandwidth utilization. It is worth mentioning that every node is responsible for transmitting different types of packets, including control messages, locally published messages, messages received from mesh members, IWANT replies, etc. As long as traffic volume is lower than the available data rate, the message forwarding mechanisms yield similar results due to negligible queuing delays. However, when the traffic volume increases and exceeds the available peer bandwidth (even for short traffic bursts), the outgoing message queue(s) sizes rise, potentially impacting the network's performance. In this scenario, FIFO-based traffic forwarding can lead to locally published messages being placed at the end of the outgoing message queue, introducing a queuing delay proportional to the queue size. The same applies to other delay-sensitive messages like IDONTWANT, PRUNE, etc. On the other hand, the segregation of traffic into priority and non-priority queues can potentially starve low-priority messages. One possible solution is to use weighted queues for a fair spread of messages. Message prioritization can be a powerful tool to ensure that important messages reach their intended recipients on time and allow for customizable message handling. For example, staggering between peers and messages can be better managed by using priority queues. However, it is important to note that message prioritization also introduces additional complexity to the system, necessitating sophisticated algorithms for better message handling.","s":"4. Message prioritization","u":"/rlog/gsub-largemsg-improvements","h":"#4-message-prioritization","p":367},{"i":383,"t":"During heartbeat intervals, GossipSub nodes transmit IHAVE messages (carrying IDs of seen messages) to the peers not included in the full-message mesh. These peers can use IWANT messages to request any missing messages. A budget counter ensures these messages never exceed a specified threshold during each heartbeat interval. The IHAVE/IWANT messages are a crucial tool in maintaining network connectivity. They bridge the information gap between nearby and far-off peers, ensuring that information can be disseminated to peers outside the mesh. This function is essential in protecting against network partitions and indirectly aids in safeguarding against Sybil and eclipse attacks. However, it is essential to understand that high transmission times for large messages require careful due diligence when using IWANT messages for reasons not limited to: A large message reception may take several hundred milliseconds to complete. During this time, an IHAVE message announcing the same message ID will trigger an IWANT request. A peer can send IWANT requests for the same message to multiple nodes, leading to simultaneous transmissions of the same message. Replying to (potentially many) IWANT requests can delay the transmission of the same message to mesh peers, resulting in lower peer scores and slower message propagation. A few possible solutions to mitigate this problem may include: Issuing IHAVE announcements only after the message is delivered to many mesh peers. Allocating a volume-based budget to service IWANT requests during each heartbeat interval. Deferring IWANT requests for messages that are currently being received. Deferring IWANT requests if at least KKK IDONTWANTs are received for the same message. A large message transmission can yield high CwndC_{wnd}Cwnd​; preferring such peers during mesh maintenance can be helpful.","s":"5. Maximizing benefits from IWANT messages","u":"/rlog/gsub-largemsg-improvements","h":"#5-maximizing-benefits-from-iwant-messages","p":367},{"i":385,"t":"This study investigates the pressing issue of considerable fluctuations and rises in network-wide dissemination times for large messages. We delve into multiple factors, such as increased message transmit times, store-and-forward delays, congestion avoidance mechanisms, and prioritization between messages, to establish a comprehensive understanding of the problem. The study also explores the performance of optimization efforts like floodpublishing, IHAVE/IWANT messages, and message forwarding strategies in the wake of large message transmissions. A key finding is that most congestion avoidance algorithms lack optimization for peer-to-peer networks. Coupling this constraint with increased message transmission times results in notable store-and-forward delays accumulating at each hop. Furthermore, the probabilistic message-forwarding nature of GossipSub further exacerbates the situation by utilizing a considerable share of available bandwidth on redundant transmissions. Therefore, approaches focused on eliminating redundant transmissions (IDONTWANT, IMReceiving, lazy sending, etc.) can prove helpful. At the same time, strategies aimed at reducing store-and-forward delays (fragmentation, staggering, prioritization, etc.) can prove beneficial. It is worth mentioning that many of the strategies suggested in this post are ideas at different stages. Some of these have already been explored and discussed to some extent [5, 17, 18]. We are nearing the completion of a comprehensive performance evaluation of these approaches and will soon share the results of our findings. Please feel free to join the discussion and leave feedback regarding this post in the VAC forum.","s":"Summary","u":"/rlog/gsub-largemsg-improvements","h":"#summary","p":367},{"i":387,"t":"[1] EIP-4844: Shard Blob Transactions. Retrieved from https://eips.ethereum.org/EIPS/eip-4844 [2] Message Propagation Times With Waku-RLN. Retrieved from https://docs.waku.org/research/research-and-studies/message-propagation/ [3] Lenient Flood Publishing. Retrieved from https://github.com/libp2p/rust-libp2p/pull/3666 [4] Disable Flood Publishing. Retrieved from https://github.com/sigp/lighthouse/pull/4383 [5] GossipSub for Big Messages. Retrieved from https://hackmd.io/X1DoBHtYTtuGqYg0qK4zJw [6] GossipSub: Lazy Sending. Retrieved from https://github.com/status-im/nim-libp2p/issues/850 [7] GossipSub: Limit Flood Publishing. Retrieved from https://github.com/vacp2p/nim-libp2p/pull/911 [8] GossipSub: Lazy Prefix Detection. Retrieved from https://github.com/vacp2p/nim-libp2p/issues/859 [9] Potential Gossip Improvement List for EIP4844. Retrieved from https://hackmd.io/@gRwfloEASH6NWWS_KJxFGQ/B18wdnNDh [10] GossipSub Specifications v1.2: IDONTWANT Message. Retrieved from https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.2.md?plain=1#L52 [11] Number of Duplicate Messages in Ethereum’s GossipSub Network. Retrieved from https://ethresear.ch/t/number-duplicate-messages-in-ethereums-gossipsub-network/19921 [12] TCP Congestion Control: Re-starting Idle Connections. Retrieved from https://datatracker.ietf.org/doc/html/rfc2581#section-4.1 [13] PING/PONG Control Messages. Retrieved from https://github.com/libp2p/specs/pull/558 [14] IHAVE/IWANT Message Impact. Retrieved from https://github.com/vacp2p/nim-libp2p/issues/1101 [15] Large Message Handling IDONTWANT + IMReceiving Messages. Retrieved from https://forum.vac.dev/t/large-message-handling-idontwant-imreceiving/281 [16] IDONTWANT Message Impact. Retrieved from https://forum.vac.dev/t/idontwant-message-impact/283 [17] IWANT Message Impact. Retrieved from https://forum.vac.dev/t/iwant-messages-may-have-negative-impact-on-message-dissemination-latency-for-large-messages/366 [18] IDONTWANT Message Performance. Retrieved from https://vac.dev/rlog/gsub-idontwant-perf-eval/","s":"References","u":"/rlog/gsub-largemsg-improvements","h":"#references","p":367},{"i":389,"t":"The original GossipSub design emphasizes robustness, with less focus on message sizes. However, emerging use cases—such as Ethereum's EIP-4844 and data availability sampling (DAS) require rapid propagation of high data volumes, often in the form of large messages. Many ongoing research efforts attempt to find solutions for efficiently forwarding large messages through the GossipSub network. This post provides a concise overview and performance evaluation of some research initiatives aimed at improving GossipSub to meet the performance needs of modern P2P networks.","s":"Scaling libp2p GossipSub for Large Messages: An Evaluation of Performance Improvement Proposals","u":"/rlog/gsub-perf-imp-comparison","h":"","p":388},{"i":391,"t":"For each subscribed topic, GossipSub nodes maintain a full-message mesh of peers with a target degree DDD, bounded by lower and upper thresholds DlowD_{low}Dlow​ and DhighD_{high}Dhigh​​, respectively. In parallel, a metadata-only (gossip) mesh includes additional KKK peers for metadata exchange. All messages flow through the full-message mesh, and metadata flows through the gossip mesh. The metadata contains IHAVE messages, announcing IDs of seen messages. Upon receiving an IHAVE announcement about an unseen message ID, a receiver responds with an IWANT request to retrieve the announced message. IHAVE announcements serve multiple purposes: Offer additional resilience in situations involving non-conforming peers or network partitions. Speed up message propagation by allowing far-off peers to fetch overdue messages. Since GossipSub v1.1 [1], replying to IWANT requests is optional, to safeguard honest peers from adversaries. This change encourages peers to make redundant IWANT requests for the same message. While this arrangement works well for small messages, it can be inefficient for bigger ones. This inefficiency arises from an increase in duplicates and a higher number of IWANT requests due to longer transmission times for large messages. As a result, we observe a significant rise in bandwidth utilization and message dissemination times across the network. IDONTWANT messages in GossipSub v1.2 [2] help reduce some duplicates. However, further efforts are necessary to mitigate this problem [3, 4]. That is why many recent works focus on improving GossipSub's performance when handling large messages [5, 6, 7, 8, 9, 10, 11, 12]. In this post, we evaluate the push-pull phase transition (PPPT) mechanism [10], the GossipSub v1.4 proposal [11, 5], and the GossipSub v2.0 proposal [12] for performance against Gossipsub v1.2. For this purpose, we implement minimal proof-of-concept (PoC) versions of these protocols in nim-libp2p [13] and use the shadow simulator to provide performance evaluation results. We begin by discussing the issues of message dissemination times and duplicate messages in GossipSub. Next, we provide a brief overview of the proposals under review, followed by the experiments and findings from our performance evaluations.","s":"Overview","u":"/rlog/gsub-perf-imp-comparison","h":"#overview","p":388},{"i":393,"t":"Assuming uniform link characteristics, message dissemination to full-message mesh concludes in τD≈(D×τtx)+τp\\tau_D \\approx (D \\times \\tau_{tx}) + \\tau_pτD​≈(D×τtx​)+τp​ time, where τtx=SR\\tau_{tx} = \\frac{S}{R}τtx​=RS​, with SSS, RRR, and τp\\tau_pτp​ being the message size, data rate, and link latency, respectively. This simplifies network-wide dissemination time to τN≈τD×h\\tau_{N} \\approx \\tau_D \\times hτN​≈τD​×h, with hhh indicating the number of hops along the longest path. This implies that a tenfold increase in message size results in an eightyfold rise in D×τtxD \\times \\tau_{tx}D×τtx​ for a mesh with D=8D = 8D=8, which accumulates across hhh hops. This leads to two fundamental problems: A longer contention interval (τD\\tau_DτD​) increases the chance that peers receive the same message from multiple mesh members during that interval, leading to redundant transmissions and more duplicates. Reducing DDD inadvertently increases hhh — potentially slowing propagation overall. Peers are unaware of ongoing message receptions and may generate redundant IWANT requests for the messages they are already receiving. Most of these requests are entertained by early message receivers, which increases message dissemination time by increasing the workload at peers situated along the optimal path. Talking about duplicates, a network comprising NNN peers, each with a degree DDD, has a total of N×D2\\frac {N \\times D}{2}2N×D​ edges (links), as every link connects two peers. Assuming that a message traverses every link exactly once, we get at least N×D2\\frac {N \\times D}{2}2N×D​ transmissions. Only N−1N-1N−1 transmissions are necessary for delivering a message to all peers. As a result, we get N×D2−(N−1)\\frac {N \\times D}{2} -(N-1)2N×D​−(N−1) duplicates in the network. We can simplify average duplicates received by a single peer to dˉmin≈D2−1\\bar{d}_{min} \\approx \\frac{D}{2}-1dˉmin​≈2D​−1. Here, dˉmin\\bar{d}_{min}dˉmin​ represents the lower bound on average duplicates because we assume that the send and receive operations are mutually exclusive. This assumption requires that message transmission times (and link latencies) are so small that no two peers simultaneously transmit the same message to each other. However, a large message can noticeably increase the contention interval, which increases the likelihood that many peers will simultaneously transmit the same message to each other. Authors in [14] explore the upper bound (dˉmax\\bar{d}_{max}dˉmax​) on duplicates. They argue that a node can forward a received message to a maximum of D−1D-1D−1 peers while the original publisher sends it to DDD peers. As a result, we get N(D−1)+1N(D-1)+1N(D−1)+1 transmissions in the network. Only N−1N-1N−1 transmissions are necessary to deliver a message to all peers. Remaining N(D−1)+1−(N−1)N(D-1)+1-(N-1)N(D−1)+1−(N−1) transmissions are duplicates, which simplifies the upper bound on average duplicates received by each peer to dˉmax≈D−2\\bar{d}_{max} \\approx D-2dˉmax​≈D−2. This rise indicates that larger messages can lead to more duplicates due to longer contention intervals. It is essential to highlight that the impact of IWANT/IDONTWANT messages is not considered in dˉ\\bar{d}dˉ computations above.","s":"Message Transfer Time and Duplicates","u":"/rlog/gsub-perf-imp-comparison","h":"#message-transfer-time-and-duplicates","p":388},{"i":396,"t":"In PPPT, authors argue that most redundant transmissions occur during the later stages of message propagation. As a message traverses through the network, the peers forwarding the message should gradually reduce the number of mesh members that directly receive the message (push) and send immediate IHAVE announcements to the remaining peers in the mesh. The remaining mesh members can fetch any missing messages using IWANT requests (Pull). The authors also suggest two strategies to estimate the message propagation stage: Include a hop count in the message header to identify the number of hops traversed by that message. When a peer forwards a received message, it performs a pull operation for a subset of mesh members that equals the specified hop count and a push operation for the remaining mesh members. Infer the message propagation stage by looking into the number of received IHAVE announcements and duplicates for that message. Use this information to choose a balance between pull-based and push-based message forwarding. The authors suggest that instead of simultaneously pushing a message to the selected peers, sequentially initiating transmission to each peer after a short delay enhances the likelihood of timely receiving a higher number of IDONTWANT requests. Key Considerations and PoC Implementation​ The use of hop count is a more effective and straightforward method for identifying the message propagation stage than relying on the duplicate count. However, this approach may compromise the publisher's anonymity and reveal information about the publisher and its mesh members. Additional due diligence may be needed to address these issues. In the PoC implementation [15], we use hop count to determine the message propagation stage. When forwarding a message, every peer selects a subset of mesh members equal to the advertised hop count for pull operation and forwards the message to the remaining mesh members. If the advertised hop count exceeds the number of mesh members chosen for message forwarding, the sender relays the message to all selected peers.","s":"Push-Pull Phase Transition (PPPT)","u":"/rlog/gsub-perf-imp-comparison","h":"#push-pull-phase-transition-pppt","p":388},{"i":398,"t":"GossipSub v1.4 proposal considers longer large-message transfer times (τD\\tau_DτD​) as contention intervals and argues that most duplicates occur during these intervals for two fundamental reasons: Peers are unaware of ongoing message receptions and may generate redundant IWANT requests for messages they are already receiving. Peers can send IDONTWANT announcements only after receiving the entire message. However, a large contention interval increases the likelihood that many redundant transmissions will start before IDONTWANT messages are issued. GossipSub v1.4 proposal eliminates contention interval with help from two new control messages: PREAMBLE and IMRECEIVING. A PREAMBLE precedes every large message transmission. Upon receiving a preamble, a peer learns about the messages it is receiving and performs two actions: Notify mesh members about ongoing message reception using an IMRECEIVING announcement. On receiving an IMRECEIVING announcement from a peer, mesh members defer sending the announced message to that peer. Defer IWANT requests for messages that are currently being received. Peers also limit the outstanding IWANT requests for any message to one. Key Considerations and PoC Implementation​ The use of PREAMBLE/IMRECEIVING addresses the limitation of IDONTWANT messages. For instance, consider a peer XXX begins receiving a message mmm at time t1t_1t1​. It can transmit IDONTWANT only after receiving mmm, i.e., at time t1+τDt_1+\\tau_Dt1​+τD​. Therefore, it can not cancel any duplicate receptions of mmm that start before t1+τD+τpt1 + \\tau_D + \\tau_pt1+τD​+τp​. In contrast, IMRECEIVING announcements for mmm start at t1+Δt_1 + \\Deltat1​+Δ, where Δ\\DeltaΔ denotes PREAMBLE processing time and satisfies Δ≪τD\\Delta \\ll \\tau_DΔ≪τD​. As a result, peer XXX can eliminate all duplicate receptions of mmm that start after t1+Δ+τpt_1 + \\Delta +\\tau_pt1​+Δ+τp​, which noticeably reduces duplicates. The use of PREAMBLE also allows deferring IWANT requests for messages we are already receiving, which can also improve message dissemination time by reducing the workload on peers along the optimal message forwarding path. It is worth mentioning that a malicious peer can exploit this approach by sending a PREAMBLE and never completing (or deliberately delaying) the promised message transfer. The optional safety strategy in GossipSub v1.4 proposal suggests using a peer score threshold for PREAMBLE processing and a behavior penalty for broken promises. A timeout strategy helps recover such messages. It is essential to mention that sending and processing of PREAMBLE and IMRECEIVING messages is optional. This flexibility allows for the use of custom safety strategies in various implementations. For example, the ongoing production-grade implementation of GossipSub v1.4 in nim-libp2p allows peers to ignore PREAMBLEs unless they come from mesh members with higher data rates (bandwidth estimation becomes trivial with PREAMBLEs) and good peer scores. This implementation also lets peers choose between a push or pull strategy for handling broken promises. For the performance evaluations in this post, we utilize the PoC implementation of GossipSub v1.4 [16]. A complete, production-grade version is currently undergoing testing and validation [17].","s":"GossipSub v1.4 Proposal","u":"/rlog/gsub-perf-imp-comparison","h":"#gossipsub-v14-proposal","p":388},{"i":400,"t":"GossipSub v2.0 introduces a hybrid method for message dissemination that combines both push and pull strategies through two new control messages: IANNOUNCE and INEED. These messages are analogous to IHAVE and IWANT messages, respectively. However, IANNOUNCE messages are issued to the mesh members immediately after validating a received message without waiting for the heartbeat interval. Similarly, INEED requests are made exclusively to mesh members, and a peer generates only one INEED request for a received message. The balance between push and pull approaches is determined by the DannounceD_{announce}Dannounce​ parameter. On receiving a message, a peer forwards it to D−DannounceD - D_{announce}D−Dannounce​ mesh members and sends IANNOUNCE messages to the remaining mesh peers. On receiving an IANNOUNCE for an unseen message, a peer can request it using an INEED message. Key Considerations and PoC Implementation​ The DannounceD_{announce}Dannounce​ parameter governs the balance between push and pull operations. Setting Dannounce=DD_{announce} = DDannounce​=D results in a pull-only operation, which can eliminate duplicates at the cost of increased message dissemination time. In contrast, setting DannounceD_{announce}Dannounce​ to zero reverts to standard GossipSub v1.2 operation. The authors suggest setting Dannounce=D−1D_{announce} = D-1Dannounce​=D−1 to moderately decrease dissemination time while incurring only a small number of duplicate transmissions. It is important to note that malicious peers can exploit this approach by delaying or entirely omitting responses to INEED requests. Similarly, sending INEED requests to suboptimal or overwhelmed peers can further increase message dissemination time. The authors propose using a timeout strategy and negative peer scoring to address these issues. If a message transfer does not complete within the specified interval, the receiver decreases the sender's peer score and issues a new INEED request to an alternative mesh member. For the performance evaluations in this post, we utilize the PoC implementation of GossipSub v2.0 [18] from nim-libp2p. We set Dannounce=D−1D_{announce} = D-1Dannounce​=D−1 and allow any peer to send a single IWANT request for a message, only if it has not previously sent an INEED request for the same message.","s":"GossipSub v2.0 Proposal","u":"/rlog/gsub-perf-imp-comparison","h":"#gossipsub-v20-proposal","p":388},{"i":402,"t":"We conducted a series of experiments under various configurations to evaluate the performance of the GossipSub v1.4 proposal, the PPPT approach, and the GossipSub v2.0 proposal against the baseline GossipSub v1.2 protocol. To support these evaluations, we extended the nim-libp2p implementation to include minimal PoC implementations of the considered protocols [16, 15, 18] and used the Shadow simulator [19] to carry out performance evaluations. For GossipSub v1.4 and PPPT, we also report results from delayed forwarding, where peers introduce a short delay before relaying a message to every mesh member. This delay helps reduce the number of redundant transmissions by increasing the likelihood of timely receiving a higher number of IDONTWANT notifications. We evaluate performance using network-wide message dissemination time (latency), network-wide bandwidth utilization (bandwidth), and the average number of duplicates received by a peer for every transmitted message. We also report the average number of IWANT requests transmitted by a peer for a single message. For each experiment, we transmit multiple messages in the network. We average the network-wide dissemination time for these messages to report latency. Bandwidth refers to the total volume of traffic in the network, encompassing control messages and data transmissions (including duplicates and IWANT replies). A peer usually receives multiple copies of any transmitted message. Excluding the first received message, all copies are duplicates. We compute average duplicates received by a peer as 1NM∑j=1M∑i=1Ndi,j\\frac{1}{N M} \\sum_{j=1}^{M} \\sum_{i=1}^{N} d_{i,j}NM1​∑j=1M​∑i=1N​di,j​ where NNN and MMM denote the number of peers and the number of transmitted messages, respectively, and di,jd_{i,j}di,j​ represents the number of duplicates received by peer iii for message jjj. A similar mechanism computes average IWANT requests. Three simulation scenarios are considered: Scenario 1: The number of publishers and message size are kept constant while the network size gradually increases. Scenario 2: The number of publishers and the network size remain constant while the message size gradually increases. Scenario 3: The number of nodes and message size remain constant while the number of publishers gradually increases. In all experiments, we transmit multiple messages such that every publisher sends exactly one message to the network. After a publisher transmits a message, each subsequent publisher waits for a specified interval (inter-message delay) before sending the next message. Rotating publishers ensures that every message traverses a different path, which helps achieve fair performance evaluation. On the other hand, changing inter-message delays allows for creating varying traffic patterns. A shorter inter-message delay implies more messages can be in transit simultaneously, which helps evaluate performance against large message counts. A longer delay ensures every message is fully disseminated before introducing a new message. Similarly, increasing message size stresses the network. As a result, we evaluate performance across a broader range of use cases. The simulation details are presented in the tables below. The experiments are conducted using the shadow simulator. We uniformly set peer bandwidths and link latencies between 40-200 Mbps and 40-130 milliseconds in five variations. Table 1: Simulation Scenarios. Experiment No. of Nodes No. of Publishers Message Size (KB) Inter-Message Delay (ms) Scenario 1 3000, 6000, 9000, 12000 7 150 10000 Scenario 2 1500 10 200, 600, 1000, 1400, 1800 10000 Scenario 3 1500 25, 50, 75, 100, 125 50 50 Table 2: Simulation Parameters. Parameter Value Parameter Value DDD 8 DlowD_{low}Dlow​ 6 DlazyD_{lazy}Dlazy​ 6 DhighD_{high}Dhigh​ 12 Gossip factor 0.05 Muxer yamux Heartbeat interval 1000 ms Floodpublish false Peer Bandwidth 40-200 Mbps Link Latency 40-130ms DannounceD_{announce}Dannounce​ GossipSub v2.0 7 Forward delay in PPPT/v1.4 with delay 35 ms","s":"Experiments","u":"/rlog/gsub-perf-imp-comparison","h":"#experiments","p":388},{"i":404,"t":"Scenario1: Increasing Network Size​ Bandwidth Latency Average Duplicates Average IWANT Requests Scenario2: Increasing Message Size​ Bandwidth Latency Average Duplicates Average IWANT Requests Scenario3: Increasing Number of Publishers​ Bandwidth Latency Average Duplicates Average IWANT Requests","s":"Results","u":"/rlog/gsub-perf-imp-comparison","h":"#results","p":388},{"i":406,"t":"The number of IWANT requests increases with the message size. Limiting ongoing IWANT requests for each message to one can be beneficial. Additionally, the use of message PREAMBLEs can help eliminate IWANT requests for messages that are already being received. Pull-based approaches can substantially reduce bandwidth utilization, but may result in much longer message dissemination times. However, these approaches can achieve simultaneous propagation of multiple messages by implicitly rotating among outgoing messages. As a result, increasing the number of messages yields similar dissemination times. Transition from push to pull operation during the later stages of message propagation can reduce bandwidth consumption, without compromising latency. However, determining the propagation stage is challenging. Methods like hop counts may compromise anonymity, while using IHAVE announcements can be misleading. For instance, in the case of large messages, peers may receive IHAVE announcements much earlier than the actual message spreads through the network. Push-based approaches achieve the fastest message dissemination but often produce a higher number of duplicate messages. Employing mechanisms like PREAMBLE/IMRECEIVING messages for guided elimination of duplicate messages can significantly reduce bandwidth consumption. This reduction not only minimizes redundant transmissions but also decreases the overall message dissemination time by lessening the workload on peers located along optimal message forwarding paths. Please feel free to join the discussion and leave feedback regarding this post in the VAC forum.","s":"Findings","u":"/rlog/gsub-perf-imp-comparison","h":"#findings","p":388},{"i":408,"t":"[1] GossipSub v1.1 Specifications [2] GossipSub v1.2 Specifications [3] Number of Duplicate Messages in Ethereum’s Gossipsub Network [4] Impact of IDONTWANT in the Number of Duplicates [5] PREAMBLE and IMRECEIVING for Improved Large Message Handling [6] Staggering and Fragmentation for Improved Large Message Handling [7] GossipSub for Big Messages [8] FullDAS: Towards Massive Scalability with 32MB Blocks and Beyond [9] Choke Extension for GossipSub [10] PPPT: Fighting the GossipSub Overhead with Push-Pull Phase Transition [11] GossipSub v1.4 Specifications Proposal [12] GossipSub v2.0 Specifications Proposal [13] Libp2p Implementation in nim [14] The Streamr Network: Performance and Scalability [15] PPPT: PoC Implementation in nim-libp2p [16] GossipSub v1.4: PoC Implementation in nim-libp2p [17] GossipSub v1.4: Production-Grade Implementation in nim-libp2p [18] GossipSub v2.0: PoC Implementation in nim-libp2p [19] nim-libp2p GossipSub Test Node","s":"References","u":"/rlog/gsub-perf-imp-comparison","h":"#references","p":388},{"i":410,"t":"A quick history of discovery in peer-to-peer networks, along with a look into discv4 and discv5, detailing what they are, how they work and where they differ. If you've been working on Ethereum or adjacent technologies you've probably heard of discv4 or discv5. But what are they actually? How do they work and what makes them different? To answer these questions, we need to start at the beginning, so this post will assume that there is little knowledge on the subject so the post should be accessible for anyone.","s":"From Kademlia to Discv5","u":"/rlog/kademlia-to-discv5","h":"","p":409},{"i":412,"t":"Let's start right at the beginning: the problem of discovery and organization of nodes in peer-to-peer networks. Early P2P file sharing technologies, such as Napster, would share information about who holds what file using a single server. A node would connect to the central server and give it a list of the files it owns. Another node would then connect to that central server, find a node that has the file it is looking for and contact that node. This however was a flawed system -- it was vulnerable to attacks and left a single party open to lawsuits. It became clear that another solution was needed, and after years of research and experimentation, we were given the distributed hash table or DHT.","s":"The Beginning","u":"/rlog/kademlia-to-discv5","h":"#the-beginning","p":409},{"i":414,"t":"In 2001 4 new protocols for such DHTs were conceived, Tapestry, Chord, CAN and Pastry, all of which made various trade-offs and changes in their core functionality, giving them unique characteristics. But as said, they're all DHTs. So what is a DHT? A distributed hash table (DHT) is essentially a distributed key-value list. Nodes participating in the DHT can easily retrieve the value for a key. If we have a network with 9 key-value pairs and 3 nodes, ideally each node would store 3 (optimally 6 for redundancy) of those key-value pairs, meaning that if a key-value pair were to be updated, only part of the network would responsible for ensuring that it is. The idea is that any node in the network would know where to find the specific key-value pair it is looking for based on how things are distributed amongst the nodes.","s":"Distributed Hash Tables","u":"/rlog/kademlia-to-discv5","h":"#distributed-hash-tables","p":409},{"i":416,"t":"So now that we know what DHTs are, let's get to Kademlia, the predecessor of discv4. Kademlia was created by Petar Maymounkov and David Mazières in 2002. I will naively say that this is probably one of the most popular and most used DHT protocols. It's quite simple in how it works, so let's look at it. In Kademlia, nodes and values are arranged by distance (in a very mathematical definition). This distance is not a geographical one, but rather based on identifiers. It is calculated how far 2 identifiers are from eachother using some distance function. Kademlia uses an XOR as its distance function. An XOR is a function that outputs true only when inputs differ. Here is an example with some binary identifiers: XOR 10011001 00110010 -------- 10101011 The top in decimal numbers means that the distance between 153 and 50 is 171. There are several reasons why XOR was taken: The distance from one ID to itself will be 0. Distance is symmetric, A to B is the same as B to A. Follows triangle inequality, if A, B and C are points on a triangle then the distance A to B is closer or equal to that of A to C plus the one from B to C. In summary, this distance function allows a node to decide what is \"close\" to it and make decisions based on that \"closeness\". Kademlia nodes store a routing table. This table contains multiple lists. Each subsequent list contains nodes which are a little further distanced than the ones included in the previous list. Nodes maintain detailed knowledge about nodes closest to them, and the further away a node is, the less knowledge the node maintains about it. So let's say I want to find a specific node. What I would do is go to any node which I already know and ask them for all their neighbours closest to my target. I repeat this process for the returned neighbours until I find my target. The same thing happens for values. Values have a certain distance from nodes and their IDs are structured the same way so we can calculate this distance. If I want to find a value, I simply look for the neighbours closest to that value's key until I find the one storing said value. For Kademlia nodes to support these functions, there are several messages with which the protocol communicates. PING - Used to check whether a node is still running. STORE - Stores a value with a given key on a node. FINDNODE - Returns the closest nodes requested to a given ID. FINDVALUE - The same as FINDNODE, except if a node stores the specific value it will return it directly. This is a very simplified explanation of Kademlia and skips various important details. For the full description, make sure to check out the paper or a more in-depth design specification","s":"Kademlia","u":"/rlog/kademlia-to-discv5","h":"#kademlia","p":409},{"i":418,"t":"Now after that history lesson, we finally get to discv4 (which stands for discovery v4), Ethereum's current node discovery protocol. The protocol itself is essentially based off of Kademlia, however it does away with certain aspects of it. For example, it does away with any usage of the value part of the DHT. Kademlia is mainly used for the organisation of the network, so we only use the routing table to locate other nodes. Due to the fact that discv4 doesn't use the value portion of the DHT at all, we can throw away the FINDVALUE and STORE commands described by Kademlia. The lookup method previously described by Kademlia describes how a node gets its peers. A node contacts some node and asks it for the nodes closest to itself. It does so until it can no longer find any new nodes. Additionally, discv4 adds mutual endpoint verification. This is meant to ensure that a peer calling FINDNODE also participates in the discovery protocol. Finally, all discv4 nodes are expected to maintain up-to-date ENR records. These contain information about a node. They can be requested from any node using a discv4-specific packet called ENRRequest. If you want some more details on ENRs, check out one of my posts \"Network Addresses in Ethereum\" Discv4 comes with its own range of problems however. Let's look at a few of them. Firstly, the way discv4 works right now, there is no way to differentiate between node sub-protocols. This means for example that an Ethereum node could add an Ethereum Classic Node, Swarm or Whisper node to its DHT without realizing that it is invalid until more communication has happened. This inability to differentiate sub-protocols makes it harder to find specific nodes, such as Ethereum nodes with light-client support. Next, in order to prevent replay attacks, discv4 uses timestamps. This however can lead to various issues when a host's clock is wrong. For more details, see the \"Known Issues\" section of the discv4 specification. Finally, we have an issue with the way mutual endpoint verification works. Messages can get dropped and there is no way to tell if both peers have verified eachother. This means that we could consider our peer verified while it does not consider us so making them drop the FINDNODE packet.","s":"Discv4","u":"/rlog/kademlia-to-discv5","h":"#discv4","p":409},{"i":420,"t":"Finally, let's look at discv5. The next iteration of discv4 and the discovery protocol which will be used by Eth 2.0. It aims at fixing various issues present in discv4. The first change is the way FINDNODE works. In traditional Kademlia as well as in discv5, we pass an identifier. However, in discv5 we instead pass the logarithmic distance, meaning that a FINDNODE request gets a response containing all nodes at the specified logarithmic distance from the called node. Logarithmic distance means we first calculate the distance and then run it through our log base 2 function. See: log2(A xor B) And the second, more important change, is that discv5 aims at solving one of the biggest issues of discv4: the differentiation of sub-protocols. It does this by adding topic tables. Topic tables are first in first out lists that contain nodes which have advertised that they provide a specific service. Nodes get themselves added to this list by registering ads on their peers. As of writing, there is still an issue with this proposal. There is currently no efficient way for a node to place ads on multiple peers, since it would require separate requests for every peer which is inefficient in a large-scale network. Additionally, it is unclear how many peers a node should place these ads on and exactly which peers to place them on. For more details, check out the issue devp2p#136. There are a bunch more smaller changes to the protocol, but they are less important hence they were ommitted from this summary. Nevertheless, discv5 still does not resolve a couple issues present in discv4, such as unreliable endpoint verification. As of writing this post, there is currently no new method in discv5 to improve the endpoint verification process. As you can see discv5 is still a work in progress and has a few large challenges to overcome. However if it does, it will most likely be a large improvement to a more naive Kademlia implementations. Hopefully this article helped explain what these discovery protocols are and how they work. If you're interested in their full specifications you can find them on github.","s":"Discv5","u":"/rlog/kademlia-to-discv5","h":"#discv5","p":409},{"i":422,"t":"Nescience, a privacy-first blockchain zkVM.","s":"Nescience - A zkVM leveraging hiding properties","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"","p":421},{"i":424,"t":"Nescience is a privacy-first blockchain project that aims to enable private transactions and provide a general-purpose execution environment for classical applications. The goals include creating a state separation architecture for public/private computation, designing a versatile virtual machine based on mainstream instruction sets, creating proofs for private state updates, implementing a kernel-based architecture for correct execution of private functions, and implementing core DeFi protocols such as AMMs and staking from a privacy perspective. It intends to create a user experience that is similar to public blockchains, but with additional privacy features that users can leverage at will. To achieve this goal, Nescience will implement a versatile virtual machine that can be used to implement existing blockchain applications, while also enabling the development of privacy-centric protocols such as private staking and private DEXs. To ensure minimal trust assumptions and prevent information leakage, Nescience proposes a proof system that allows users to create proofs for private state updates, while the verification of the proofs and the execution of the public functions inside the virtual machine can be delegated to an external incentivised prover. It also aims to implement a seamless interaction between public and private state, enabling composability between contracts, and private and public functions. Finally, Nescience intends to implement permissive licensing, which means that the source code will be open-source, and developers will be able to use and modify the code without any restriction. Our primary objective is the construction of the Zero-Knowledge Virtual Machine (zkVM). This document serves as a detailed exploration of the multifaceted challenges, potential solutions, and alternatives that lay ahead. Each step is a testament to our commitment to thoroughness; we systematically test various possibilities and decisively commit to the one that demonstrates paramount performance and utility. For instance, as we progress towards achieving Goal 2, we are undertaking a rigorous benchmarking of the Nova proof system against its contemporaries. Should Nova showcase superior performance metrics, we stand ready to integrate it as our proof system of choice. Through such meticulous approaches, we not only reinforce the foundation of our project but also ensure its scalability and robustness in the ever-evolving landscape of blockchain technology.","s":"Introduction","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#introduction","p":421},{"i":426,"t":"The initial goal revolves around crafting a distinctive architecture that segregates public and private computations, employing an account-based framework for the public state and a UTXO-based structure for the private state. The UTXO model [1,2], notably utilized in Bitcoin, generates new UTXOs to serve future transactions, while the account-based paradigm assigns balances to accounts that transactions can modify. Although the UTXO model bolsters privacy by concealing comprehensive balances, the pursuit of a dual architecture mandates a meticulous synchronization of these state models, ensuring that private transactions remain inconspicuous in the wider public network state. This task is further complicated by the divergent transaction processing methods intrinsic to each model, necessitating a thoughtful and innovative approach to harmonize their functionality. To seamlessly bring together the dual architecture, harmonizing the account-based model for public state with the UTXO-based model for private state, a comprehensive strategy is essential. The concept of blending an account-based structure with a UTXO-based model for differentiating between public and private states is intriguing. It seeks to leverage the strengths of both models: the simplicity and directness of the account-based model with the privacy enhancements of the UTXO model. Here's a breakdown and a potential strategy for harmonizing these models:","s":"Goal 1: Create a State Separation Architecture","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-1-create-a-state-separation-architecture","p":421},{"i":428,"t":"Account-Based Model: This model is intuitive and easy to work with. Every participant has an account, and transactions directly modify the balances of these accounts. It's conducive for smart contracts and a broad range of applications. UTXO-Based Model: This model treats every transaction as a new output, which can then be used as an input for future transactions. By not explicitly associating transaction outputs with user identities, it offers a degree of privacy.","s":"Rationale Behind the Dual Architecture:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-rationale-behind-the-dual-architecture-","p":421},{"i":430,"t":"Translation Layer Role: Interface between UTXO and account-based states. UTXO-to-Account Adapter: When UTXOs are spent, the adapter can translate these into the corresponding account balance modifications. This could involve creating a temporary 'pseudo-account' that mirrors the UTXO's attributes. Account-to-UTXO Adapter: When an account wishes to make a private transaction, it would initiate a process converting a part of its balance to a UTXO, facilitating a privacy transaction. Unified Identity Management Role: Maintain a unified identity (or address) system that works across both state models, allowing users to easily manage their public and private states without requiring separate identities. Deterministic Wallets: Use Hierarchical Deterministic (HD) wallets [3,4], enabling users to generate multiple addresses (both UTXO and account-based) from a single seed. This ensures privacy while keeping management centralized for the user. State Commitments Role: Use cryptographic commitments to commit to the state of both models. This can help in efficiently validating cross-model transactions. Verkle Trees: Verkle Trees combine Vector Commitment and the KZG polynomial commitment scheme to produce a structure that's efficient in terms of both proofs and verification. Verkle proofs are considerably small in size (less data to store and transmit), where Transaction and state verifications can be faster due to the smaller proof sizes and computational efficiencies. Mimblewimble-style Aggregation [5]: For UTXOs, techniques similar to those used in Mimblewimble can be used to aggregate transactions, keeping the state compact and enhancing privacy. Batch Processing & Anonymity Sets Role: Group several UTXO-based private transactions into a single public account-based transaction. This can provide a level of obfuscation and can make synchronization between the two models more efficient. CoinJoin Technique [6]: As seen in Bitcoin, multiple users can combine their UTXO transactions into one, enhancing privacy. Tornado Cash Principle [7]: For account-based systems wanting to achieve privacy, methods like those used in Tornado Cash can be implemented, providing zk-SNARKs-based private transactions. Event Hooks & Smart Contracts Role: Implement event-driven mechanisms that trigger specific actions in one model based on events in the other. For instance, a private transaction (UTXO-based) can trigger a corresponding public notification or event in the account-based model. Conditional Execution: Smart contracts could be set to execute based on events in the UTXO system. For instance, a smart contract might release funds (account-based) once a specific UTXO is spent. Privacy Smart Contracts: Using zk-SNARKs or zk-STARKs to bring privacy to the smart contract layer, allowing for private logic execution.","s":"Harmonizing the Two Systems:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-harmonizing-the-two-systems-","p":421},{"i":432,"t":"Synchronization Overhead Challenge: Combining two distinct transaction models creates an inherent synchronization challenge. State Channels: By allowing transactions to be conducted off-chain between participants, state channels can alleviate synchronization stresses. Only the final state needs to be settled on-chain, drastically reducing the amount of data and frequency of updates required. Sidechains: These act as auxiliary chains to the main blockchain. Transactions can be processed on the sidechain and then periodically synced with the main chain. This structure helps reduce the immediate load on the primary system. Checkpointing: Introduce periodic checkpoints where the two systems' states are verified and harmonized. This can ensure consistency without constant synchronization. Double Spending Challenge: With two models operating in tandem, there's an increased risk of double-spending attacks. Multi-Signature Transactions: Implementing transactions that require signatures from both systems can prevent unauthorized movements. Cross-Verification Mechanisms: Before finalizing a transaction, it undergoes verification in both UTXO and account-based systems. If discrepancies arise, the transaction can be halted. Timestamping: By attaching a timestamp to each transaction, it's possible to order them sequentially, making it easier to spot and prevent double spending. Complexity in User Experience Challenge: The dual model, while powerful, is inherently complex. Abstracted User Interfaces: Design UIs that handle the complexity behind the scenes, allowing users to make transactions without needing to understand the nuances of the dual model. Guided Tutorials: Offer onboarding tutorials to acquaint users with the system's features, especially emphasizing when and why they might choose one transaction type over the other. Feedback Systems: Implement systems where users can provide feedback on any complexities or challenges they encounter. This real-time feedback can be invaluable for iterative design improvements. Security Challenge: Merging two systems can introduce unforeseen vulnerabilities. Threat Modeling: Regularly conduct threat modeling exercises to anticipate potential attack vectors, especially those that might exploit the interaction between the two systems. Layered Security Protocols: Beyond regular audits, introduce multiple layers of security checks. Each layer can act as a fail-safe if a potential threat bypasses another. Decentralized Watchtowers: These are third-party services that monitor the network for malicious activities. If any suspicious activity is detected, they can take corrective measures or raise alerts. Gas & Fee Management: Challenge: A dual model can lead to convoluted fee structures. Dynamic Fee Adjustment: Implement algorithms that adjust fees based on network congestion and transaction type. This can ensure fairness and prevent network abuse. Fee Estimation Tools: Provide tools that can estimate fees before a transaction is initiated. This helps users understand potential costs upfront. Unified Gas Stations: Design platforms where users can purchase or allocate gas for both transaction types simultaneously, simplifying the gas acquisition process. By addressing these challenges head-on with a detailed and systematic approach, it's possible to unlock the full potential of a dual-architecture system, combining the strengths of both UTXO and account-based models without their standalone limitations. Aspect Details Harmony - Advanced VM Development: Design tailored for private smart contracts. - Leverage Established Architectures: Use WASM or RISC-V to harness their versatile and encompassing nature suitable for zero-knowledge applications. - Support for UTXO & Account-Based Models: Enhance adaptability across various blockchain structures. Challenges - Adaptation Concerns: WASM and RISC-V weren't designed with zero-knowledge proofs as a primary focus, posing integration challenges. - Complexities with Newer Systems: Systems like (Super)Nova, STARKs, and Sangria are relatively nascent, adding another layer of intricacy to the integration. - Optimization Concerns: Ensuring that these systems are optimized for zero-knowledge proofs. Proposed Solutions - Integration of Nova: Consider Nova's proof system for its potential alignment with project goals. - Comprehensive Testing: Rigorously test and benchmark against alternatives like Halo2, Plonky, and Starky to validate choices. - Poseidon Recursion Technique: To conduct exhaustive performance tests, providing insights into each system's efficiency and scalability.","s":"Challenges and Solutions","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-challenges-and-solutions-","p":421},{"i":434,"t":"The second goal entails the creation of an advanced virtual machine by leveraging established mainstream instruction sets like WASM or RISC-V. Alternatively, the objective involves pioneering a new, specialized instruction set meticulously optimized for Zero-Knowledge applications. This initiative seeks to foster a versatile and efficient environment for executing computations within the privacy-focused context of the project. Both WASM and RISC-V exhibit adaptability to both UTXO and account-based models due to their encompassing nature as general-purpose instruction set architectures. WASM, operating as a low-level virtual machine, possesses the capacity to execute code derived from a myriad of high-level programming languages, and boasts seamless integration across diverse blockchain platforms. Meanwhile, RISC-V emerges as a versatile option, accommodating both models, and can be seamlessly integrated with secure enclaves like SGX or TEE, elevating the levels of security and privacy. However, it is crucial to acknowledge that employing WASM or RISC-V might present challenges, given their original design without specific emphasis on optimizing for Zero-Knowledge Proofs (ZKPs). Further complexity arises with the consideration of more potent proof systems like (Super)Nova, STARKs, and Sangria, which, while potentially addressing optimization concerns, necessitate extensive research and testing due to their relatively nascent status within the field. This accentuates the need for a judicious balance between established options and innovative solutions in pursuit of an architecture harmoniously amalgamating privacy, security, and performance. The ambition to build a powerful virtual machine tailored to zero-knowledge (ZK) applications is both commendable and intricate. The combination of two renowned instruction sets, WASM and RISC-V, in tandem with ZK, is an innovation that could redefine privacy standards in blockchain. Let's dissect the challenges and possibilities inherent in this goal: Established Mainstream Instruction Sets - WASM and RISC-V Strengths: WASM: Rooted in its ability to execute diverse high-level language codes, its potential for cross-chain compatibility makes it a formidable contender. Serving as a low-level virtual machine, its role in the blockchain realm is analogous to that of the Java Virtual Machine in the traditional computing landscape. RISC-V: This open-standard instruction set architecture has made waves due to its customizable nature. Its adaptability to both UTXO and account-based structures coupled with its compatibility with trusted execution environments like SGX and TEE augments its appeal, especially in domains that prioritize security and privacy. Challenges: Neither WASM nor RISC-V was primarily designed with ZKPs in mind. While they offer flexibility, they might lack the necessary optimizations for ZK-centric tasks. Adjustments to these architectures might demand intensive R&D efforts. Pioneering a New, Specialized Instruction Set Strengths: A bespoke instruction set can be meticulously designed from the ground up with ZK in focus, potentially offering unmatched performance and optimizations tailored to the project's requirements. Challenges: Crafting a new instruction set is a monumental task requiring vast resources, including expertise, time, and capital. It would also need to garner community trust and support over time. Contemporary Proof Systems - (Super)Nova, STARKs, Sangria Strengths: These cutting-edge systems, being relatively new, might offer breakthrough cryptographic efficiencies that older systems lack: designed with modern challenges in mind, they could potentially bridge the gap where WASM and RISC-V might falter in terms of ZKP optimization. Challenges: Their nascent nature implies a dearth of exhaustive testing, peer reviews, and potentially limited community support. The unknowns associated with these systems could introduce unforeseen vulnerabilities or complexities. While they could offer optimizations that address challenges presented by WASM and RISC-V, their young status demands rigorous vetting and testing. Mainstream (WASM, RISC-V) ZK-optimized (New Instruction Set) Existing Tooling YES NO Blockchain-focused NO YES Performant DEPENDS YES","s":"Goal 2: Virtual Machine Creation","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-2-virtual-machine-creation","p":421},{"i":436,"t":"Cryptography Libraries: ZKP applications rely heavily on specific cryptographic primitives. Neither WASM nor RISC-V natively supports all of these primitives. Thus, a comprehensive library of cryptographic functions, optimized for these platforms, needs to be developed. Parallel Execution: Given the heavy computational demands of ZKPs, leveraging parallel processing capabilities can optimize the time taken. Both WASM and RISC-V would need modifications to handle parallel execution of ZKP processes efficiently. Memory Management: ZKP computations can sometimes require significant amounts of memory, especially during the proof generation phase. Fine-tuned memory management mechanisms are essential to prevent bottlenecks.","s":"Optimization Concerns for WASM and RISC-V:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-optimization-concerns-for-wasm-and-risc-v-","p":421},{"i":438,"t":"Proof Size: Different systems generate proofs of varying sizes. A smaller proof size is preferable for blockchain applications to save on storage and bandwidth. The trade-offs between proof size, computational efficiency, and security need to be balanced. Universality: Some systems can support any computational statement (universal), while others might be tailored to specific tasks. A universal system can be more versatile for diverse applications on the blockchain. Setup Requirements: Certain ZKP systems, like zk-SNARKs, require a trusted setup, which can be a security concern. Alternatives like zk-STARKs don't have this requirement but come with other trade-offs.","s":"Emerging ZKP Optimized Systems Considerations:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-emerging-zkp-optimized-systems-considerations-","p":421},{"i":440,"t":"Iterative Development: Given the complexities, an iterative development approach can be beneficial. Start with a basic integration of WASM or RISC-V for general tasks and gradually introduce specialized ZKP functionalities. Benchmarking: Establish benchmark tests specifically for ZKP operations. This will provide continuous feedback on the performance of the system as modifications are made, ensuring optimization. External Audits & Research: Regular checks from cryptographic experts and collaboration with academic researchers can help in staying updated and ensuring secure implementations.","s":"Strategies for Integration:","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-strategies-for-integration-","p":421},{"i":442,"t":"The process of generating proofs for private state updates is vested in the hands of the user, aligning with our commitment to minimizing trust assumptions and enhancing privacy. Concurrently, the responsibility of verifying these proofs and executing public functions within the virtual machine can be effectively delegated to an external prover, a role that is incentivized to operate with utmost honesty and integrity. This intricate balance seeks to safeguard against information leakage, preserving the confidentiality of private transactions. Integral to this mechanism is the establishment of a robust incentivization framework. To ensure the prover’s steadfast commitment to performing tasks with honesty, we should introduce a mechanism that facilitates both rewards for sincere behavior and penalties for any deviation from the expected standards. This two-pronged approach serves as a compelling deterrent against dishonest behavior and fosters an environment of accountability. In addition to incentivization, a crucial consideration is the economic aspect of verification and execution. The verification process has been intentionally designed to be more cost-effective than execution. This strategic approach prevents potential malicious actors from exploiting the system by flooding it with spurious proofs, a scenario that could arise when the costs align favorably. By maintaining a cost balance that favors verification, we bolster the system’s resilience against fraudulent activities while ensuring its efficiency. In sum, our multifaceted approach endeavors to strike an intricate equilibrium between user-initiated proof creation, external verification, and incentivization. This delicate interplay of mechanisms ensures a level of trustworthiness that hinges on transparency, accountability, and economic viability. As a result, we are poised to cultivate an ecosystem where users’ privacy is preserved, incentives are aligned, and the overall integrity of the system is fortified against potential adversarial actions. To achieve the goals of user-initiated proof creation, external verification, incentivization, and cost-effective verification over execution, several options and mechanisms can be employed: User-Initiated Proof Creation: Users are entrusted with the generation of proofs for private state updates, thus ensuring greater privacy and reducing trust dependencies. Challenges: Maintaining the quality and integrity of the proofs generated by users. Ensuring that users have the tools and knowledge to produce valid proofs. Solutions: Offer extensive documentation, tutorials, and user-friendly tools to streamline the proof-generation process. Implement checks at the verifier's end to ensure the quality of proofs. External Verification by Provers: An external prover verifies the proofs and executes public functions within the virtual machine. Challenges: Ensuring that the external prover acts honestly. Avoiding centralized points of failure. Solutions: Adopt a decentralized verification approach, with multiple provers cross-verifying each other’s work. Use reputation systems to rank provers based on their past performances, creating a trust hierarchy. ** Incentivization Framework:** A system that rewards honesty and penalizes dishonest actions, ensuring provers' commitment to the task. Challenges: Determining the right balance of rewards and penalties. Ensuring that the system cannot be gamed for undue advantage. Solutions1: Implement a dynamic reward system that adjusts based on network metrics and provers' performance. Use a staking mechanism where provers need to lock up a certain amount of assets. Honest behavior earns rewards, while dishonest behavior could lead to loss of staked assets. Economic Viability through Cost Dynamics: Making verification more cost-effective than execution to deter spamming and malicious attacks. Challenges: Setting the right cost metrics for both verification and execution. Ensuring that genuine users aren’t priced out of the system. Solutions: Use a dynamic pricing model, adjusting costs in real-time based on network demand. Implement gas-like mechanisms to differentiate operation costs and ensure fairness. ** Maintaining Trustworthiness:** Create a system that's transparent, holds all actors accountable, and is economically sound. Challenges: Keeping the balance where users feel their privacy is intact, while provers feel incentivized. Ensuring the system remains resilient against adversarial attacks. Solutions: Implement layered checks and balances. Foster community involvement, allowing them to participate in decision-making, potentially through a decentralized autonomous organization (DAO). Each of these options can be combined or customized to suit the specific requirements of your project, striking a balance between user incentives, cost dynamics, and verification integrity. A thoughtful combination of these mechanisms ensures that the system remains robust, resilient, and conducive to the objectives of user-initiated proof creation, incentivized verification, and cost- effective validation. Aspect Details Design Principle - User Responsibility: Generating proofs for private state updates. - External Prover: Delegated the task of verifying proofs and executing public VM functions. Trust & Privacy - Minimized Trust Assumptions: Place proof generation in users' hands. - Enhanced Privacy: Ensure confidentiality of private transactions and prevent information leakage. Incentivization Framework - Rewards: Compensate honest behavior. - Penalties: Deter and penalize dishonest behavior. Economic Considerations - Verification vs. Execution: Make verification more cost-effective than execution to prevent spurious proofs flooding. - Cost Balance: Strengthen resilience against fraudulent activities and maintain efficiency. Outcome An ecosystem where: - Users' privacy is paramount. - Incentives are appropriately aligned. - The system is robust against adversarial actions.","s":"Goal 3: Proofs Creation and Verification","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-3-proofs-creation-and-verification","p":421},{"i":444,"t":"This goal centers on the establishment of a kernel-based architecture, akin to the model observed in ZEXE, to facilitate the attestation of accurate private function executions. This innovative approach employs recursion to construct a call stack, which is then validated through iterative recursive computations. At its core, this technique harnesses a recursive Succinct Non-Interactive Argument of Knowledge (SNARK) mechanism, where each function call’s proof accumulates within the call stack. The subsequent verification of this stack’s authenticity leverages recursive SNARK validation. While this method offers robust verification of private function executions, it’s essential to acknowledge its associated intricacies. The generation of SNARK proofs necessitates a substantial computational effort, which, in turn, may lead to elevated gas fees for users. Moreover, the iterative recursive computations could potentially exhibit computational expansion as the depth of recursion increases. This calls for a meticulous balance between the benefits of recursive verification and the resource implications it may entail. In essence, Goal 4 embodies a pursuit of enhanced verification accuracy through a kernel-based architecture. By weaving recursion and iterative recursive computations into the fabric of our system, we aim to establish a mechanism that accentuates the trustworthiness of private function executions, while conscientiously navigating the computational demands that ensue. To accomplish the goal of implementing a kernel-based architecture for recursive verification of private function executions, several strategic steps and considerations can be undertaken: recursion handling and depth management. Recursion Handling Call Stack Management: Implement a data structure to manage the call stack, recording each recursive function call’s details, parameters, and state. _Proof Accumulation: _ Design a mechanism to accumulate proof data for each function call within the call stack. This includes cryptographic commitments, intermediate results, and cryptographic challenges. Ensure that the accumulated proof data remains secure and tamper-resistant throughout the recursion process. Intermediary SNARK Proofs: Develop an intermediary SNARK proof for each function call’s correctness within the call stack. This proof should demonstrate that the function executed correctly and produced expected outputs. Ensure that the intermediary SNARK proof for each recursive call can be aggregated and verified together, maintaining the integrity of the entire call stack. Depth management Depth Limitation: Define a threshold for the maximum allowable recursion depth based on the system’s computational capacity, gas limitations, and performance considerations. Implement a mechanism to prevent further recursion beyond the defined depth limit, safeguarding against excessive computational growth. Graceful Degradation: Design a strategy for graceful degradation when the recursion depth approaches or reaches the defined limit. This may involve transitioning to alternative execution modes or optimization techniques. Communicate the degradation strategy to users and ensure that the system gracefully handles scenarios where recursion must be curtailed. Resource Monitoring: Develop tools to monitor resource consumption (such as gas usage and computational time) as recursion progresses. Provide real-time feedback to users about the cost and impact of recursive execution. Dynamic Depth Adjustment: Consider implementing adaptive depth management that dynamically adjusts the recursion depth based on network conditions, transaction fees, and available resources. Utilize algorithms to assess the optimal recursion depth for efficient execution while adhering to gas cost constraints. Fallback Mechanisms: Create fallback mechanisms that activate if the recursion depth limit is reached or if the system encounters resource constraints. These mechanisms could involve alternative verification methods or delayed execution. User Notifications: Notify users when the recursion depth limit is approaching, enabling them to make informed decisions about the complexity of their transactions and potential resource usage. Goal 4 underscores the project's ambition to integrate the merits of a kernel-based architecture with recursive verifications to bolster the reliability of private function executions. While the approach promises robust outcomes, it's pivotal to maneuver through its intricacies with astute strategies, ensuring computational efficiency and economic viability. By striking this balance, the architecture can realize its full potential in ensuring trustworthy and efficient private function executions.","s":"Goal 4: Kernel-based Architecture Implementation","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-4-kernel-based-architecture-implementation","p":421},{"i":446,"t":"Goal 5 revolves around the meticulous design of a seamless interaction between public and private states within the blockchain ecosystem. This objective envisions achieving not only composability between contracts but also the harmonious integration of private and public functions. A notable challenge in this endeavor lies in the intricate interplay between public and private states, wherein the potential linkage of a private transaction to a public one raises concerns about unintended information leakage. The essence of this goal entails crafting an architecture that facilitates the dynamic interaction of different states while ensuring that the privacy and confidentiality of private transactions remain unbreached. This involves the formulation of mechanisms that enable secure composability between contracts, guaranteeing the integrity of interactions across different layers of functionality. A key focus of this goal is to surmount the challenge of information leakage by implementing robust safeguards. The solution involves devising strategies to mitigate the risk of revealing private transaction details when connected to corresponding public actions. By creating a nuanced framework that com- partmentalizes private and public interactions, the architecture aims to uphold privacy while facilitating seamless interoperability. Goal 5 encapsulates a multifaceted undertaking, calling for the creation of an intricate yet transparent framework that empowers users to confidently engage in both public and private functions, without compromising the confidentiality of private transactions. The successful realization of this vision hinges on a delicate blend of architectural ingenuity, cryptographic sophistication, and user-centric design. To achieve seamless interaction between public and private states, composability, and privacy preservation, a combination of solutions and approaches can be employed. In the table below, a comprehensive list of solutions that address these objectives: Solution Category Description Layer 2 Solutions Employ zk-Rollups, Optimistic Rollups, and state channels to handle private interactions off-chain and settle them on-chain periodically. Boost scalability and cut transaction costs. Intermediary Smart Contracts Craft smart contracts as intermediaries for secure public-private interactions. Use these to manage data exchange confidentially. Decentralized Identity & Pseudonymity Implement decentralized identity systems for pseudonymous interactions. Validate identity using cryptographic proofs. Confidential Sidechains & Cross-Chain Set up confidential sidechains and employ cross-chain protocols to ensure private and composability across blockchains. Temporal Data Structures Create chronological data structures for secure interactions. Utilize cryptographic methods for data integrity and privacy. Homomorphic Encryption & MPC Apply homomorphic encryption and MPC for computations on encrypted data and interactions between state layers. Commit-Reveal Schemes Introduce commit-reveal mechanisms for private transactions, revealing data only post necessary public actions. Auditability & Verifiability Use on-chain tools for auditing and verifying interactions. Utilize cryptographic commitments for third-party validation. Data Fragmentation & Sharding Fragment data across shards for private interactions and curtailed data exposure. Bridge shards securely with cryptography. Ring Signatures & CoinJoin Incorporate ring signatures and CoinJoin protocols to mask transaction details and mix transactions collaboratively.","s":"Goal 5: Seamless Interaction Design","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-5-seamless-interaction-design","p":421},{"i":448,"t":"The primary aim of Goal 6 is to weave key DeFi protocols, such as AMMs and staking, into a user-centric environment that accentuates privacy. This endeavor comes with inherent challenges, especially considering the heterogeneity of existing DeFi protocols, predominantly built on Ethereum. These variations in programming languages and VMs exacerbate the quest for interoperability. Furthermore, the success and functionality of DeFi protocols is closely tied to liquidity, which in turn is influenced by user engagement and the amount of funds locked into the system.","s":"Goal 6: Integration of DeFi Protocols with a Privacy-Preserving Framework","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#goal-6-integration-of-defi-protocols-with-a-privacy-preserving-framework","p":421},{"i":450,"t":"** Pioneering Privacy-Centric DeFi Models: ** Initiate the development of AMMs and staking solutions that are inherently protective of users' transactional privacy and identity. ** Specialized Smart Contracts with Privacy: ** Architect distinct smart contracts infused with privacy elements, setting the stage for secure user interactions within this new, confidential DeFi landscape. ** Optimized User Interfaces: ** Craft interfaces that resonate with user needs, simplifying the journey through the private DeFi space without compromising on security. ** Tackling Interoperability: ** Deploy advanced bridge technologies and middleware tools to foster efficient data exchanges and guarantee operational harmony across a spectrum of programming paradigms and virtual environments. Design and enforce universal communication guidelines that bridge the privacy-centric DeFi entities with the larger DeFi world seamlessly. ** Enhancing and Sustaining Liquidity: ** Unveil innovative liquidity stimuli and yield farming incentives, compelling users to infuse liquidity into the private DeFi space. Incorporate adaptive liquidity frameworks that continually adjust based on the evolving market demands, ensuring consistent liquidity. Forge robust alliances with other DeFi stalwarts, jointly maximizing liquidity stores and honing sustainable token distribution strategies. ** Amplifying Community Engagement:** Design and roll out enticing incentive schemes to rally users behind privacy-focused AMMs and staking systems, thereby nurturing a vibrant, privacy-advocating DeFi community. Through the integration of these approaches, we aim to achieve Goal 6, providing users with a privacy-focused platform for engaging effortlessly in core DeFi functions such as AMMs and staking, all while effectively overcoming the obstacles related to interoperability and liquidity concerns.","s":"Strategic Roadmap for Goal 6","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#-strategic-roadmap-for-goal-6-","p":421},{"i":452,"t":"In our quest to optimize privacy, we're proposing a Zero-Knowledge Virtual Machine (Zkvm) that harnesses the power of Zero-Knowledge Proofs (ZKPs). These proofs ensure that while private state data remains undisclosed, public state transitions can still be carried out and subsequently verified by third parties. This blend of public and private state is envisaged to be achieved through a state tree representing the public state, while the encrypted state leaves stand for the private state. Each user's private state indicates validity through the absence of a corresponding nullifier. A nullifier is a unique cryptographic value generated in privacy-preserving blockchain transactions to prevent double-spending, ensuring that each private transaction is spent only once without revealing its details. Private functions' execution mandates users to offer a proof underscoring the accurate execution of all encapsulated private calls. For validating a singular private function call, we're leaning into the kernel-based model inspired by the ZEXE protocol. Defined as kernel circuits, these functions validate the correct execution of each private function call. Due to their recursive circuit structure, a succession of private function calls can be executed by calculating proofs in an iterative manner. Execution-relevant data, like private and public call stacks and additions to the state tree, are incorporated as public inputs. Our method integrates the verification keys for these functions within a merkle tree. Here's the innovation: a user's ZKP showcases the existence of the verification key in this tree, yet keeps the executed function concealed. The unique function identifier can be presented as the verification key, with all contracts merkleized for hiding functionalities. We suggest a nuanced shift from the ZEXE protocol's identity function, which crafts an identity for smart contracts delineating its behavior, access timeframes, and other functionalities. Instead of the ZEXE protocol's structure, our approach pivots to a method anchored in the security of a secret combined with the uniqueness from hashing with the contract address. The underlying rationale is straightforward: the sender, equipped with a unique nonce and salt for the transaction, hashes the secret, payload, nonce, and salt. This result is then hashed with the contract address for the final value. The hash function's unidirectional nature ensures that the input cannot be deduced easily from its output. A specific concern, however, is the potential repetition of secret and payload values across transactions, which could jeopardize privacy. Yet, by embedding the function's hash within the hash of the contract address, users can validate a specific function's execution without divulging the function, navigating this limitation. Alternative routes do exist: We could employ signature schemes like ECDSA, focusing on uniqueness and authenticity, albeit at the cost of complex key management. Fully Homomorphic Encryption (FHE) offers another pathway, enabling function execution on encrypted data, or Multi-Party Computation (MPC) which guarantees non-disclosure of function or inputs. Yet, integrating ZKPs with either FHE or MPC presents a challenge. Combining cryptographic functions like SHA-3 and BLAKE2 can also bolster security and uniqueness. It's imperative to entertain these alternatives, especially when hashing might not serve large input/output functions effectively or might fall short in guaranteeing uniqueness.","s":"Summary of the Architecture","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#summary-of-the-architecture","p":421},{"i":454,"t":"Our aim is to revolutionize the privacy and security paradigms through Nescience. As we strive to set milestones and achieve groundbreaking advancements, our current focus narrows onto the realization of Goal 2 and Goal 3. Our endeavors to build a powerful virtual machine tailored for Zero-Knowledge applications have led us down the path of rigorous exploration and testing. We believe that integrating the right proof system is pivotal to our project's success, which brings us to Nova [8]. In our project journey, we have opted to integrate the Nova proof system, recognizing its potential alignment with our overarching goals. However, as part of our meticulous approach to innovation and optimization, we acknowledge the need to thoroughly examine Nova’s performance capabilities, particularly due to its status as a pioneering and relatively unexplored proof system. This critical evaluation entails a comprehensive process of benchmarking and comparative analysis [9], pitting Nova against other prominent proof systems in the field, including Halo2 [10], Plonky2 [11], and Starky [12]. This ongoing and methodical initiative is designed to ensure a fair and impartial assessment, enabling us to draw meaningful conclusions about Nova’s strengths and limitations in relation to its counterparts. By leveraging the Poseidon recursion technique, we are poised to conduct an exhaustive performance test that delves into intricate details. Through this testing framework, we aim to discern whether Nova possesses the potential to outshine its contemporaries in terms of efficiency, scalability, and overall performance. The outcome of this rigorous evaluation will be pivotal in shaping our strategic decisions moving forward. Armed with a comprehensive understanding of Nova’s performance metrics vis-à-vis other proof systems, we can confidently chart a course that maximizes the benefits of our project’s optimization efforts. Moreover, as we ambitiously pursue the establishment of a robust mechanism for proof creation and verification, our focus remains resolute on preserving user privacy, incentivizing honest behaviour, and ensuring the cost-effective verification of transactions. At the heart of this endeavor is our drive to empower users by allowing them the autonomy of generating proofs for private state updates, thereby reducing dependencies and enhancing privacy. We would like to actively work on providing comprehensive documentation, user-friendly tools, and tutorials to aid users in this intricate process. Parallelly, we're looking into decentralized verification processes, harnessing the strength of multiple external provers that cross-verify each other's work. Our commitment is further cemented by our efforts to introduce a dynamic reward system that adjusts based on network metrics and prover performance. This intricate balance, while challenging, aims to fortify our system against potential adversarial actions, aligning incentives, and preserving the overall integrity of the project.","s":"Current State","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#current-state","p":421},{"i":456,"t":"[1] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. Retrieved from https://bitcoin.org/bitcoin.pdf [2] Sanchez, F. (2021). Cardano’s Extended UTXO accounting model. Retrived from https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/ [3] Morgan, D. (2020). HD Wallets Explained: From High Level to Nuts and Bolts. Retrieved from https://medium.com/mycrypto/the-journey-from-mnemonic-phrase-to-address-6c5e86e11e14 [4] Wuille, P. (012). Bitcoin Improvement Proposal (BIP) 44. Retrieved from https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki [5] Jedusor, T. (2020). Introduction to Mimblewimble and Grin. Retrieved from https://github.com/mimblewimble/grin/blob/master/doc/intro.md [6] Bitcoin's official wiki overview of the CoinJoin method. Retrieved from https://en.bitcoin.it/wiki/CoinJoin [7] TornadoCash official Github page. Retrieved from https://github.com/tornadocash/tornado-classic-ui [8] Kothapalli, A., Setty, S., Tzialla, I. (2021). Nova: Recursive Zero-Knowledge Arguments from Folding Schemes. Retrieved from https://eprint.iacr.org/2021/370 [9] ZKvm Github page. Retrieved from https://github.com/vacp2p/zk-explorations [10] Electric Coin Company (2020). Explaining Halo 2. Retrieved from https://electriccoin.co/blog/explaining-halo-2/ [11] Polygon Labs (2022). Introducing Plonky2. Retrieved from https://polygon.technology/blog/introducing-plonky2 [12] StarkWare (2021). ethSTARK Documentation. Retrieved from https://eprint.iacr.org/2021/582 Footnotes​ Incentive Mechanisms: Token Rewards: Design a token-based reward system where honest provers are compensated with tokens for their verification services. This incentivizes participation and encourages integrity. Staking and Slashing: Introduce a staking mechanism where provers deposit tokens as collateral. Dishonest behavior results in slashing (partial or complete loss) of the staked tokens, while honest actions are rewarded. Proof of Work/Proof of Stake: Implement a proof-of-work or proof-of- stake consensus mechanism for verification, aligning incentives with the blockchain’s broader consensus mechanism. ↩","s":"References","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"","p":421},{"i":458,"t":"Incentive Mechanisms: Token Rewards: Design a token-based reward system where honest provers are compensated with tokens for their verification services. This incentivizes participation and encourages integrity. Staking and Slashing: Introduce a staking mechanism where provers deposit tokens as collateral. Dishonest behavior results in slashing (partial or complete loss) of the staked tokens, while honest actions are rewarded. Proof of Work/Proof of Stake: Implement a proof-of-work or proof-of- stake consensus mechanism for verification, aligning incentives with the blockchain’s broader consensus mechanism. ↩","s":"Footnotes","u":"/rlog/Nescience-A-zkVM-leveraging-hiding-properties","h":"#footnote-label","p":421},{"i":460,"t":"Welcome to the first edition of Nim in Logos — a newsletter covering major Nim features from Logos' perspective. If you have comments or suggestions, feel free to reach out to the authors directly or start a thread in the Logos Discord server.","s":"Nim in Logos - 1st Edition","u":"/rlog/nim-in-logos-01","h":"","p":459},{"i":462,"t":"The Nim 2.2 release series focuses on improving language stability, fixing long-standing bugs, and optimizing performance—particularly in the ORC memory management system. The latest patch in this series, version 2.2.4, continues to build on these goals. Here are some of the key highlights from the 2.2 series: More powerful generics and type expressions: Stabilization of generics, typedesc, and static types. These features now support arbitrary expressions that previously only worked in limited cases, making them more reliable. Improved tuple unpacking: Tuple unpacking now supports discarding values using underscores (_) and allows inline type annotations for unpacked elements. Memory leak fixes: Issues with memory leaks when using std/nre’s regular expressions or nested exceptions have been resolved. More efficient async code: Futures no longer always copy data, resulting in better performance in asynchronous workflows. String bug fixes: Several issues involving string and cstring usage have been corrected. In addition to core language improvements: NimSuggest stability: The language server has received multiple fixes, improving the experience in IDEs and editors that rely on NimSuggest for autocompletion and error checking. Better code generation: Numerous issues related to invalid or broken C and C++ code generation and backend-specific bugs have been addressed, improving Nim’s reliability when targeting other languages. You can read the full release announcement and changelog here","s":"Nim 2.2 – Better Stability, Smarter Memory, and Smoother Development","u":"/rlog/nim-in-logos-01","h":"#nim-22---better-stability-smarter-memory-and-smoother-development","p":459},{"i":464,"t":"Error handling is one of the most critical aspects of writing reliable software, yet it remains a contentious topic in many programming languages. In Nim, developers face a unique challenge: multiple error handling paradigms are supported, leading to confusion about which approach to choose. For robust, maintainable code, our answer at Logos is increasingly clear—favor Result types over exceptions. The Exception Problem​ While exceptions might seem convenient for quick scripts and prototypes, they introduce significant challenges in complex, long-running applications: Silent API Changes: One of the most dangerous aspects of exception-based error handling is that changes deep within dependencies can break your code without any compile-time warning. When a function suddenly starts throwing a new exception type, your code may fail at runtime under exceptional circumstances—often when you least expect it. Resource Management Issues: Exceptions create unpredictable control flow that can lead to resource leaks, security vulnerabilities, and unexpected crashes. When an exception unwinds the stack, resources may not be properly cleaned up. Refactoring Difficulties: The compiler provides little assistance when working with exception-based code. Adding a new exception type breaks the ABI but leaves the API unchanged, making it nearly impossible to track down all the places that need updating. The Result Advantage​ The Result type offers a compelling alternative that makes error handling explicit, predictable, and compiler-verified: # Enforce that no exceptions can't be raised in this module {.push raises: [].} import results proc doSomething(): Result[void, string] = # Implementation here proc getRandomInt(): Result[int, string] = # Implementation here doSomething().isOkOr: echo \"Failed doing something, error: \", & error randomInt = getRandomInt().valueOr: echo \"Failed getting random int, error: \", & error Notice that this usage of Result is much more concise and easier to follow than try-except blocks Best Practices for Result-Based Error Handling​ Make Errors Explicit: Use Result when multiple failure paths exist and calling code needs to differentiate between them. This makes error handling visible at the call site and forces developers to consciously handle failure cases. Handle Errors Locally: Address errors at each abstraction level rather than letting them bubble up through multiple layers. This prevents spurious abstraction leakage and keeps error handling logic close to where problems occur. Use Exception Tracking: Enable exception tracking with {.push raises: [].} at the module level. This helps identify any remaining exception-throwing code and ensures new code follows the Result pattern. When to Break the Rules​ While Result should be your default choice, exceptions still have their place: Assertions and Logic Errors: Use assertions for violated preconditions or situations where recovery isn't possible or expected. Legacy Integration: When interfacing with exception-heavy libraries, you may need to use exceptions at integration boundaries, but convert them to Result types as quickly as possible. To ensure safe exception handling, explicitly declare which exceptions a procedure may raise using the {.raises: [SpecificException].} pragma. Error handling in Nim continues to evolve, but the trend is clear: explicit error handling through Result types provides better safety, maintainability, and debugging experience than exceptions. By making errors part of your function signatures and forcing explicit handling at call sites, you create more robust software that fails gracefully and predictably.","s":"Error Handling in Nim: Why Results Beat Exceptions","u":"/rlog/nim-in-logos-01","h":"#error-handling-in-nim-why-results-beat-exceptions","p":459},{"i":466,"t":"Nowadays, analyzing the behavior of a Nim program is not as straightforward as debugging a C++ application, for example. GDB​ GDB can be used, and step-by-step debugging with GDB and VSCode is possible. However, the interaction is not very smooth. You can set breakpoints in VSCode and press F5 to run the program up to the breakpoint and continue debugging from there. That said, the state of variables is not fully demangled. For example: For that reason, GDB is not the preferred option in Logos Logs - Chronicles​ At Logos, we primarily debug Nim applications using log outputs. In particular, we make extensive use of the nim-chronicles library. nim-chronicles is a robust logging library that automatically includes the following contextual information in each log entry: Calling thread ID Current timestamp Log level (e.g., TRACE, DEBUG, INFO, WARN, ERROR, FATAL) Source file name Line number of the log statement Additionally, chronicles supports attaching custom log messages along with relevant variable values, which proves especially useful for debugging. For instance, in the following example, the log message is \"Configuration. Shards\", and it includes the value of an additional variable, shard. INF 2025-07-01 09:56:57.705+02:00 Configuration. Shards topics=\"waku conf\" tid=28817 file=waku_conf.nim:147 shard=64 There are also useful techniques for displaying more detailed information about specific variables: repr(p) — Returns a string representation of the variable p, providing a more comprehensive view of its contents. name(typeof(p)) — Extracts the type of the variable p as a string. This is particularly helpful when working with pointers or generics. Logs - echo​ The echo statement in Nim serves as a basic debugging tool, although it is less powerful and flexible compared to nim-chronicles. Besides, debugEcho is an interesting alternative, which behaves similarly to echo but it allows working on routines marked with no side effects. Heaptrack​ This technique enables precise insight into where memory is being consumed within a Nim application. It is particularly useful for identifying potential memory leaks and is widely employed in nwaku (Nim Waku). For more details, refer to the documentation: Heaptrack Tutorial.","s":"Debugging in Nim","u":"/rlog/nim-in-logos-01","h":"#debugging-in-nim","p":459},{"i":468,"t":"Maintaining a consistent code format is essential for readability and for facilitating clear diff comparisons during code reviews. To support this, Logos strongly recommends using nph across all Nim projects.","s":"Formatting code in Nim","u":"/rlog/nim-in-logos-01","h":"#formatting-code-in-nim","p":459},{"i":470,"t":"A research log. Reliable and decentralized, pick two. Together with decanus, I've been working on the problem of data sync lately. In building p2p messaging systems, one problem you quickly come across is the problem of reliably transmitting data. If there's no central server with high availability guarantees, you can't meaningfully guarantee that data has been transmitted. One way of solving this problem is through a synchronization protocol. There are many synchronization protocols out there and I won't go into detail of how they differ with our approach here. Some common examples are Git and Bittorrent, but there are also projects like IPFS, Swarm, Dispersy, Matrix, Briar, SSB, etc.","s":"P2P Data Sync for Mobile","u":"/rlog/p2p-data-sync-for-mobile","h":"","p":469},{"i":472,"t":"Why do we want to do p2p sync for mobilephones in the first place? There are three components to that question. One is on the value of decentralization and peer-to-peer, the second is on why we'd want to reliably sync data at all, and finally why mobilephones and other resource restricted devices.","s":"Problem motivation","u":"/rlog/p2p-data-sync-for-mobile","h":"#problem-motivation","p":469},{"i":474,"t":"For decentralization and p2p, there are both technical and social/philosophical reasons. Technically, having a user-run network means it can scale with the number of users. Data locality is also improved if you query data that's close to you, similar to distributed CDNs. The throughput is also improved if there are more places to get data from. Socially and philosophically, there are several ways to think about it. Open and decentralized networks also relate to the idea of open standards, i.e. compare the longevity of AOL with IRC or Bittorrent. One is run by a company and is shut down as soon as it stops being profitable, the others live on. Additionally increasingly control of data and infrastructure is becoming a liability. By having a network with no one in control, everyone is. It's ultimately a form of democratization, more similar to organic social structures pre Big Internet companies. This leads to properties such as censorship resistance and coercion resistance, where we limit the impact a 3rd party might have a voluntary interaction between individuals or a group of people. Examples of this are plentiful in the world of Facebook, Youtube, Twitter and WeChat.","s":"Why p2p?","u":"/rlog/p2p-data-sync-for-mobile","h":"#why-p2p","p":469},{"i":476,"t":"At risk of stating the obvious, reliably syncing data is a requirement for many problem domains. You don't get this by default in a p2p world, as it is unreliable with nodes permissionslessly join and leave the network. In some cases you can get away with only ephemeral data, but usually you want some kind of guarantees. This is a must for reliable group chat experience, for example, where messages are expected to arrive in a timely fashion and in some reasonable order. The same is true for messages there represent financial transactions, and so on.","s":"Why reliably sync data?","u":"/rlog/p2p-data-sync-for-mobile","h":"#why-reliably-sync-data","p":469},{"i":478,"t":"Most devices people use daily are mobile phones. It's important to provide the same or at least similar guarantees to more traditional p2p nodes that might run on a desktop computer or computer. The alternative is to rely on gateways, which shares many of the drawbacks of centralized control and prone to censorship, control and surveillence. More generally, resource restricted devices can differ in their capabilities. One example is smartphones, but others are: desktop, routers, Raspberry PIs, POS systems, and so on. The number and diversity of devices are exploding, and it's useful to be able to leverage this for various types of infrastructure. The alternative is to centralize on big cloud providers, which also lends itself to lack of democratization and censorship, etc.","s":"Why mobilephones?","u":"/rlog/p2p-data-sync-for-mobile","h":"#why-mobilephones","p":469},{"i":480,"t":"For requirements or design goals for a solution, here's what we came up with. MUST sync data reliably between devices. By reliably we mean having the ability to deal with messages being out of order, dropped, duplicated, or delayed. MUST NOT rely on any centralized services for reliability. By centralized services we mean any single point of failure that isn’t one of the endpoint devices. MUST allow for mobile-friendly usage. By mobile-friendly we mean devices that are resource restricted, mostly-offline and often changing network. MAY use helper services in order to be more mobile-friendly. Examples of helper services are decentralized file storage solutions such as IPFS and Swarm. These help with availability and latency of data for mostly-offline devices. MUST have the ability to provide casual consistency. By casual consistency we mean the commonly accepted definition in distributed systems literature. This means messages that are casually related can achieve a partial ordering. MUST support ephemeral messages that don’t need replication. That is, allow for messages that don’t need to be reliabily transmitted but still needs to be transmitted between devices. MUST allow for privacy-preserving messages and extreme data loss. By privacy-preserving we mean things such as exploding messages (self-destructing messages). By extreme data loss we mean the ability for two trusted devices to recover from a, deliberate or accidental, removal of data. MUST be agnostic to whatever transport it is running on. It should not rely on specific semantics of the transport it is running on, nor be tightly coupled with it. This means a transport can be swapped out without loss of reliability between devices.","s":"Minimal Requirements","u":"/rlog/p2p-data-sync-for-mobile","h":"#minimal-requirements","p":469},{"i":482,"t":"The first minimum viable version is in an alpha stage, and it has a specification, implementation and we have deployed it in a console client for end to end functionality. It's heavily inspired by Bramble Sync Protocol. The spec is fairly minimal. You have nodes that exchange records over some secure transport. These records are of different types, such as OFFER, MESSAGE, REQUEST, and ACK. A peer keep tracks of the state of message for each node it is interacting with. There's also logic for message retransmission with exponential delay. The positive ACK and retransmission model is quite similar to how TCP is designed. There are two different modes of syncing, interactive and batch mode. See sequence diagrams below. Interactive mode: Batch mode: Which mode should you choose? It's a tradeoff of latency and bandwidth. If you want to minimize latency, batch mode is better. If you care about preserving bandwidth interactive mode is better. The choice is up to each node.","s":"MVDS - a minimium viable version","u":"/rlog/p2p-data-sync-for-mobile","h":"#mvds---a-minimium-viable-version","p":469},{"i":484,"t":"Initial ad hoc bandwidth and latency testing shows some issues with a naive approach. Running with the default simulation settings: communicating nodes: 2 nodes using interactive mode: 2 interval between messages: 5s time node is offine: 90% nodes each node is sharing with: 2 we notice a huge overhead. More specifically, we see a ~5 minute latency overhead and a bandwidth multiplier of x100-1000, i.e. 2-3 orders of magnitude just for receiving a message with interactive mode, without acks. Now, that seems terrible. A moment of reflection will reveal why that is. If each node is offline uniformly 90% of the time, that means that each record will be lost 90% of the time. Since interactive mode requires offer, request, payload (and then ack), that's three links just for Bob to receive the actual message. Each failed attempt implies another retransmission. That means we have (1/0.1)^3 = 1000 expected overhead to receive a message in interactive mode. The latency follows naturally from that, with the retransmission logic.","s":"Basic simulation","u":"/rlog/p2p-data-sync-for-mobile","h":"#basic-simulation","p":469},{"i":486,"t":"The problem above hints at the requirements 3 and 4 above. While we did get reliable syncing (requirement 1), it came at a big cost. There are a few ways of getting around this issue. One is having a store and forward model, where some intermediary node picks up (encrypted) messages and forwards them to the recipient. This is what we have in production right now at Status. Another, arguably more pure and robust, way is having a remote log, where the actual data is spread over some decentralized storage layer, and you have a mutable reference to find the latest messages, similar to DNS. What they both have in common is that they act as a sort of highly-available cache to smooth over the non-overlapping connection windows between two endpoints. Neither of them are required to get reliable data transmission.","s":"Mostly-offline devices","u":"/rlog/p2p-data-sync-for-mobile","h":"#mostly-offline-devices","p":469},{"i":488,"t":"While we do want better simulations, and this is a work in progress, we can also look at the above scenarios using some basic calculations. This allows us to build a better intuition and reason about the problem without having to write code. Let's start with some assumptions: two nodes exchanging a single message in batch mode 10% uniformly random uptime for each node in HA cache case, 100% uptime of a piece of infrastructure C retransmission every epoch (with constant or exponential backoff) only looking at average (p50) case First case, no helper services​ A sends a message to B, and B acks it. A message -> B (10% chance of arrival) A <- ack B (10% chance of arrival) With a constant backoff, A will send messages at epoch 1, 2, 3, .... With exponential backoff and a multiplier of 2, this would be 1, 2, 4, 8, .... Let's assume constant backoff for now, as this is what will influence the success rate and thus the bandwidth multiplier. There's a difference between time to receive and time to stop sending. Assuming each send attempt is independent, it takes on average 10 epochs for A's message to arrive with B. Furthermore: A will send messages until it receives an ACK. B will send ACK if it receives a message. To get an average of one ack through, A needs to send 100 messages, and B send on average 10 acks. That's a multiplier of roughly a 100. That's roughly what we saw with the simulation above for receiving a message in interactive mode. Second case, high-availability caching layer​ Let's introduce a helper node or piece of infrastructure, C. Whenever A or B sends a message, it also sends it to C. Whenever A or B comes online, it queries for messages with C. A message -> B (10% chance of arrival) A message -> C (100% chance of arrival) B <- req/res -> C (100% chance of arrival) A <- ack B (10% chance of arrival) C <- ack B (100% chance of arrival) A <- req/res -> C (100% chance of arrival) What's the probability that A's messages will arrive at B? Directly, it's still 10%. But we can assume it's 100% that C picks up the message. (Giving C a 90% chance success rate doesn't materially change the numbers). B will pick up A's message from C after an average of 10 epochs. Then B will send ack to A, which will also be picked up by C 100% of the time. Once A comes online again, it'll query C and receive B's ack. Assuming we use exponential backoff with a multiplier of 2, A will send a message directly to B at epoch 1, 2, 4, 8 (assuming it is online). At this point, epoch 10, B will be online in the average case. These direct sends will likely fail, but B will pick the message up from C and send one ack, both directly to A and to be picked up by C. Once A comes online, it'll query C and receive the ack from B, which means it won't do any more retransmits. How many messages have been sent? Not counting interactions with C, A sends 4 (at most) and B 1. Depending on if the interaction with C is direct or indirect (i.e. multicast), the factor for interaction with C will be ~2. This means the total bandwidth multiplier is likely to be <10, which is a lot more acceptable. Since the syncing semantics are end-to-end, this is without relying on the reliablity of C. Caveat​ Note that both of these are probabilistic argument. They are also based on heuristics. More formal analysis would be desirable, as well as better simulations to experimentally verify them. In fact, the calculations could very well be wrong!","s":"Basic calculations for bandwidth multiplier","u":"/rlog/p2p-data-sync-for-mobile","h":"#basic-calculations-for-bandwidth-multiplier","p":469},{"i":490,"t":"There are many enhancements that can be made and are desirable. Let's outline a few. Data sync clients. Examples of actual usage of data sync, with more interesting domain semantics. This also includes usage of sequence numbers and DAGs to know what content is missing and ought to be synced. Remote log. As alluded to above, this is necessary. It needs a more clear specification and solid proof of concepts. More efficient ways of syncing with large number of nodes. When the number of nodes goes up, the algorithmic complexity doesn't look great. This also touches on things such as ambient content discovery. More robust simulations and real-world deployments. Exisiting simulation is ad hoc, and there are many improvements that can be made to gain more confidence and identify issues. Additionally, better formal analysis. Example usage over multiple transports. Including things like sneakernet and meshnets. The described protocol is designed to work over unstructured, structured and private p2p networks. In some cases it can leverage differences in topology, such as multicast, or direct connections.","s":"Future work","u":"/rlog/p2p-data-sync-for-mobile","h":"#future-work","p":469},{"i":493,"t":"September 26, 2024 by Moudy 12 min read","s":"zkVM Testing Report: Evaluating Zero-Knowledge Virtual Machines for Nescience","u":"/rlog/page/2","h":"","p":491},{"i":495,"t":"August 27, 2024 by Moudy 24 min read","s":"Exploring zkVMs: Which Projects Truly Qualify as Zero-Knowledge Virtual Machines?","u":"/rlog/page/2","h":"","p":491},{"i":497,"t":"August 23, 2024 by Moudy 87 min read","s":"Nescience: A User-Centric State-Separation Architecture","u":"/rlog/page/2","h":"","p":491},{"i":499,"t":"July 19, 2024 by Marvin 13 min read","s":"Vac 101: Membership with Bloom Filters and Cuckoo Filters","u":"/rlog/page/2","h":"","p":491},{"i":501,"t":"May 13, 2024 by Aaryamann 7 min read","s":"RLN-v3: Towards a Flexible and Cost-Efficient Implementation","u":"/rlog/page/2","h":"","p":491},{"i":503,"t":"May 3, 2024 by Aaryamann 5 min read","s":"Verifying RLN Proofs in Light Clients with Subtrees","u":"/rlog/page/2","h":"","p":491},{"i":505,"t":"November 7, 2023 by Aaryamann 7 min read","s":"Strengthening Anonymous DoS Prevention with Rate Limiting Nullifiers in Waku","u":"/rlog/page/2","h":"","p":491},{"i":507,"t":"November 6, 2023 by Umar Farooq 14 min read","s":"GossipSub Improvements: Evolution of Overlay Design and Message Dissemination in Unstructured P2P Networks","u":"/rlog/page/2","h":"","p":491},{"i":509,"t":"August 28, 2023 by Moudy 32 min read","s":"Nescience - A zkVM leveraging hiding properties","u":"/rlog/page/2","h":"","p":491},{"i":511,"t":"April 24, 2023 by Richard 5 min read","s":"Device Pairing in Js-waku and Go-waku","u":"/rlog/page/2","h":"","p":491},{"i":513,"t":"This article introduces MDSECheck method — a novel approach to checking square MDS matrices for unconditional security as the components of affine permutation layers of P-SP-networks.","s":"The MDSECheck method: choosing secure square MDS matrices for P-SP-networks","u":"/rlog/mdsecheck-method","h":"","p":512},{"i":515,"t":"Maximum distance separable (MDS) matrices play a significant role in algebraic coding theory and symmetric cryptography. In particular, square MDS matrices are commonly used in affine permutation layers of partial substitution-permutation networks (P-SPNs). These are widespread designs of the modern symmetric ciphers and hash functions. A classic example of the latter is Poseidon [1], a well-known hash function used in zk-SNARK proving systems. Square MDS matrices differ in terms of security that they are able to provide for P-SPNs. The use of some such matrices in certain P-SPNs may result in existence of infinitely long subspace trails of small period for the latter, which make them vulnerable to differential cryptanalysis [2]. Two methods for security checking of square MDS matrices for P-SPNs have been proposed in [2]. The first one, which is referred to as the three tests method in the rest of the article, is aimed at security checking for a specified structure of the substitution layer of a P-SPN. The second method, which is referred here as the sufficient test method, has been designed to determine whether a square MDS matrix satisfies a sufficient condition of being secure regardless of the structure of a P-SPN substitution layer, i.e. to check whether the matrix belongs to the class of square MDS matrices, which are referred to as unconditionally secure in the current article. This article aims to introduce MDSECheck method — a novel approach to checking square MDS matrices for unconditional security, which has already been implemented in the Rust programming language as the library crate [3]. The next sections explain the notions mentioned above, describe the MDSECheck method as well as its mathematical foundations, provide a brief overview of the MDSECheck library crate and outline possible future research directions.","s":"Introduction","u":"/rlog/mdsecheck-method","h":"#introduction","p":512},{"i":517,"t":"An mmm x nnn matrix MMM over a finite field is called MDS, if and only if for distinct nnn-dimensional column vectors v1v_1v1​ and v2v_2v2​ the column vectors v1 ∣ Mv1v_1 \\: | \\: M v_1v1​∣Mv1​ and v2 ∣ Mv2v_2 \\: | \\: M v_2v2​∣Mv2​, where ∣|∣ stands for vertical concatenation, do not coincide in nnn or more components. The set of all possible column vectors v ∣ Mvv \\: | \\: M vv∣Mv for some fixed matrix MMM is a systematic MDS code, i.e. a linear code, which contains input symbols on their original positions and achieves the Singleton bound. The latter property results in good error-correction capability. There are several equivalent definitions of MDS matrices, but the next one is especially useful for constructing them directly by means of algebraic methods. A matrix over a finite field is called MDS, if and only if all its square submatrices are nonsingular. The matrix entries and the matrix itself are also considered submatrices. One of the most efficient and straightforward methods to directly construct an MDS matrix is generating a Cauchy matrix [4]. Such an mmm x nnn matrix is defined using mmm-dimensional vector xxx and nnn-dimensional vector yyy, for which all entries in the concatenation of xxx and yyy are distinct. The entries of the Cauchy matrix are described by the formula Mi,j=1 / (xi−yj)M_{i, j} = 1 \\: / \\: (x_i - y_j)Mi,j​=1/(xi​−yj​). It is obvious that any submatrix of a Cauchy matrix is also a Cauchy matrix. The Cauchy determinant formula [5] implies that every square Cauchy matrix is nonsingular. Thus, Cauchy matrices satisfy the second definition of MDS matrices.","s":"MDS matrix: how to define and construct","u":"/rlog/mdsecheck-method","h":"#mds-matrix-how-to-define-and-construct","p":512},{"i":519,"t":"Describing SPNs in algebraic terms is convenient, so this approach has been chosen for this article. SPNs are designs of the symmetric cryptoprimitives, which operate on an internal state, which is represented as an nnn-dimensional vector over some finite field, and update this state iteratively by means of the round transformations described below. Each round begins with an optional update of the internal state by adding to its components some input data or extraction of some of these components as the output data. This optional step depends on the specific cryptoprimitive and the current round number. The next step is called the nonlinear substitution layer and lies in replacing the iii-th component of the internal state with Si(c)S_i(c)Si​(c) for each i∈[1..n]i \\in [1..n]i∈[1..n], where ccc is the component value and Si(x)S_i(x)Si​(x) is a nonlinear invertible function over the finite field. The function Si(x)S_i(x)Si​(x) is specific to the cryptoprimitive and called an S-Box. The final step, which is known as the affine permutation layer, replaces the internal state with MX+cM X + cMX+c, where XXX is the current internal state, MMM is a nonsingular square matrix and ccc is the vector of the round constants. The value of ccc is specific to the cryptoprimitive and the current round number, while MMM typically depends only on the cryptoprimitive. The data flow diagram for an SPN is given below. .................................. │ │ │ │ ▼ ▼ ▼ ▼ ┌────────────────────────────────┐ │ Optional addition / extraction │ <─────> Input / output └──┬────────┬────────┬────────┬──┘ ▼ ▼ ▼ ▼ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │S₁(x)│ │S₂(x)│ │ ... │ │Sₙ(x)│ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ ▼ ▼ ▼ ▼ ┌────────────────────────────────┐ │ Affine permutation │ └──┬────────┬────────┬────────┬──┘ ▼ ▼ ▼ ▼ ┌────────────────────────────────┐ │ Optional addition / extraction │ <─────> Input / output └──┬────────┬────────┬────────┬──┘ ▼ ▼ ▼ ▼ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │S₁(x)│ │S₂(x)│ │ ... │ │Sₙ(x)│ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ ▼ ▼ ▼ ▼ ┌────────────────────────────────┐ │ Affine permutation │ └──┬────────┬────────┬────────┬──┘ ▼ ▼ ▼ ▼ .................................. Partial SPNs are modifications of SPNs, where for certain rounds some S-Boxes are replaced with the identity functions to reduce computational efforts [2]. For example, the nonlinear substitution layers of the partial rounds of Poseidon update only the first internal state component [1]. In the case of P-SPNs, security considerations commonly demand to choose MMM as a square MDS matrix, because these matrices provide perfect diffusion property for the affine permutation layer [6]. Possessing this property means ensuring that any two nnn-dimensional internal states, which differ in exactly ttt components, are mapped by the affine permutation layer to two new internal states that differ in at least n−t+1n - t + 1n−t+1 components.","s":"Partial substitution-permutation networks","u":"/rlog/mdsecheck-method","h":"#partial-substitution-permutation-networks","p":512},{"i":521,"t":"Certain square MDS matrices should not be used in certain P-SPNs to avoid making them vulnerable to differential cryptanalysis, since it may exploit the existence of infinitely long subspace trails of small period for vulnerable P-SPNs. [2]. Such matrices are called insecure with respect to particular P-SPNs. An infinitely long subspace trail of period lll exists for a P-SPN, if and only if there is a proper subspace of differences of internal state vectors, such that if for a pair of initial internal states the difference belongs to this subspace, then the difference for the new internal states, which are obtained from the initial ones by means of the same lll-round transformation, also belongs to this subspace [2]. Two methods for checking square MDS matrices for suitability for P-SPNs in terms of existence of infinitely long subspace trails have been proposed in [2]. The three tests method is aimed at checking whether using a specified matrix for a P-SPN with a specified structure of the substitution layer leads to existence of infinitely long subspace trails of period ppp for this P-SPN for all ppp no larger than a given lll. The sufficient test method has been designed to determine whether a square MDS matrix satisfies a sufficient condition of non-existence of infinitely long subspace trails of period ppp for P-SPNs using this matrix for all ppp no larger than a specified lll. The sufficient test method is a direct consequence of Theorem 8 in [2] and consists in checking that the minimal polynomial of the ppp-th power of the tested matrix has maximum degree and is irreducible for all p∈[1..l]p \\in [1..l]p∈[1..l]. The aforesaid sufficient non-existence condition is satisfied by the matrix, if and only if all the checks yield positive results. It is convenient to define the unconditional P-SPN security level of the square MDS matrix as follows: this level is lll for the matrix MMM, if and only if the minimal polynomials of MMM, M2M^2M2, ........., MlM^lMl have maximum degree and are irreducible, but for Ml + 1M^{l \\: + \\: 1}Ml+1 the minimal polynomial does not have this property. Using this definition, the purpose of the sufficient test method can be described as checking whether the unconditional P-SPN security level of the specified matrix is no less than a given bound.","s":"Square MDS matrix security check in the context of P-SPNs","u":"/rlog/mdsecheck-method","h":"#square-mds-matrix-security-check-in-the-context-of-p-spns","p":512},{"i":523,"t":"The MDSECheck method, whose name is derived from the words \"MDS\", \"security\", \"elaborated\" and \"check\", has the same purpose as the sufficient test method, but achieves it differently. The differences of the first method from the latter and approaches to implementing them can be described as follows: Computation and verification of minimal polynomials of M2M^2M2, M3M^3M3, ........., MlM^lMl, where MMM is the tested nnn x nnn matrix over GF(q)GF(q)GF(q) and lll is the security level bound, has been replaced with checks for the corresponding powers of a root of the characteristic polynomial of MMM for non-presence in nontrivial subfields of GF(qn)GF(q^n)GF(qn). The non-presence check is performed without straightforward consideration of all nontrivial subfields of GF(qn)GF(q^n)GF(qn). The root is checked only for non-presence in the subfields GF(qn / p1)GF(q^{n \\: / \\: p_1})GF(qn/p1​), GF(qn / p2)GF(q^{n \\: / \\: p_2})GF(qn/p2​), ........., GF(qn / pd)GF(q^{n \\: / \\: p_d})GF(qn/pd​), where p1p_1p1​, p2p_2p2​, ........., pdp_dpd​ are all prime divisors of nnn. The non-presence check reuses some data computed during the checking for irreducibility the minimal polynomial of MMM, which in this case coincides with f(y)f(y)f(y) designating the characteristic polynomial of MMM. The values of yqn / pjmod f(y)y^{q^{n \\: / \\: p_j}} \\mod f(y)yqn/pj​modf(y) are saved for each j∈[1..d]j \\in [1..d]j∈[1..d] during the irreducibility check to replace exponentiations with sequential computations of (yi)qn / pjmod f(y)(y^i)^{q^{n \\: / \\: p_j}} \\mod f(y)(yi)qn/pj​modf(y) from (y(i − 1))qn / pjmod f(y)(y^{(i \\: - \\: 1)})^{q^{n \\: / \\: p_j}} \\mod f(y)(y(i−1))qn/pj​modf(y) as its product with yqn / pjmod f(y)y^{q^{n \\: / \\: p_j}} \\mod f(y)yqn/pj​modf(y). The check of the minimal polynomial of MMM for irreducibility and maximum degree is performed without unconditional computation of this polynomial. This computation has been replaced with the Krylov method fragment, which consists in building and solving only one system of linear equations over GF(q)GF(q)GF(q). If MMM has an irreducible minimal polynomial of maximum degree, then its coefficients are trivially determined from the system solution. If the system is degenerate, then the minimal polynomial of MMM does not have such properties. The correctness of the first distinctive feature can be proven as follows. Verifying that the minimal polynomial of a matrix is of maximum degree and irreducible is equivalent to verifying that the characteristic polynomial of this matrix is irreducible, because the minimal polynomial divides the characteristic one. Also, it is trivially proven that for a matrix with such a minimal polynomial it is equal to the characteristic polynomial. Thus, the required checks for the matrices M2M^2M2, M3M^3M3, ........., MlM^lMl can be done by checking their characteristic polynomials for irreducibility. Let MMM be nnn x nnn matrix over GF(q)GF(q)GF(q), whose minimal polynomial is of maximum degree and irreducible. The statements in the previous paragraph imply that f(y)f(y)f(y), which is the nnn-degree characteristic polynomial of MMM, is irreducible. Consider MMM over the extension field GF(qn)GF(q^n)GF(qn), which is the splitting field of f(y)f(y)f(y). Let α∈GF(qn)α \\in GF(q^n)α∈GF(qn) be a root of f(y)f(y)f(y). According to standard results from the Galois field theory, ααα, αqα^qαq, αq2α^{q^2}αq2, ........., αqn − 1α^{q^{n \\: - \\: 1}}αqn−1 are distinct roots of f(y)f(y)f(y) [7]. Thus, these powers of ααα are nnn distinct eigenvalues of MMM. Hence, due to matrix similarity properties, there is some matrix SSS such that SMS−1=DS M S^{-1} = DSMS−1=D, where DDD is the diagonal matrix, whose nonzero elements are ααα, αqα^qαq, αq2α^{q^2}αq2, ........., αqn − 1α^{q^{n \\: - \\: 1}}αqn−1. Therefore, SMiS−1=DiS M^i S^{-1} = D^iSMiS−1=Di, so the roots of the characteristic polynomial of MiM^iMi are αiα^iαi, (αq)i(α^q)^i(αq)i, (αq2)i(α^{q^2})^i(αq2)i, ........., (αqn − 1)i(α^{q^{n \\: - \\: 1}})^i(αqn−1)i. If the minimal polynomial of αiα^iαi has degree less than nnn, then the characteristic polynomial of MiM^iMi is divisible by this minimal polynomial, while αiα^iαi lies in some nontrivial subfield of GF(qn)GF(q^n)GF(qn). One of the fields isomorphic to this subfield is a residue class ring of polynomials modulo the minimal polynomial of αiα^iαi [7]. If the minimal polynomial of αiα^iαi is of degree nnn, then the characteristic polynomial of MiM^iMi equals this minimal polynomial and therefore is irreducible, while αiα^iαi does not lie in any nontrivial subfield of GF(qn)GF(q^n)GF(qn). In this case, 111, αiα^iαi, (αi)2(α^i)^2(αi)2, ........., (αi)n − 1(α^i)^{n \\: - \\: 1}(αi)n−1 are linearly independent as distinct roots of an irreducible polynomial over a finite field [7], so any field containing αiα^iαi has at least qnq^nqn elements and therefore cannot be a trivial subfield of GF(qn)GF(q^n)GF(qn). Thus, checking the characteristic polynomials of the matrices M2M^2M2, M3M^3M3, ........., MlM^lMl for irreducibility is equivalent to verifying that α2α^2α2, α3α^3α3, ........., αlα^lαl do not lie in any nontrivial subfield of GF(qn)GF(q^n)GF(qn). The last sentences of the two previous paragraphs imply the following: verifying that the minimal polynomials of M2M^2M2, M3M^3M3, ........., MlM^lMl are of maximum degree and irreducible can be performed by verifying that the corresponding powers of a root of the characteristic polynomial of the nnn x nnn matrix MMM over GF(q)GF(q)GF(q) do not belong to any nontrivial subfield of GF(qn)GF(q^n)GF(qn). ■\\blacksquare■ The approaches to implementing the first distinctive feature can be explained and proven to be correct as follows. Since GF(qw)GF(q^w)GF(qw) is a nontrivial subfield of GF(qu)GF(q^u)GF(qu) if and only if www divides uuu and w