Ethereum'un güvenliğini ve merkeziyetsizliğini korumasının az tartışılan ancak yine de çok önemli bir yolu, çoklu istemci felsefesidir. Ethereum'un kasıtlı olarak herkesin varsayılan olarak çalıştırdığı bir "referans istemcisi" yoktur: bunun yerine, işbirliği içinde yönetilen bir spesifikasyon vardır (bu günlerde çok insan tarafından okunabilir ancak çok yavaş Python 'da yazılmıştır) ve kullanıcıların gerçekte çalıştırdığı spesifikasyonun ("istemciler" olarak da adlandırılır) uygulamalarını yapan birden fazla ekip vardır.

Her Ethereum düğümü bir mutabakat istemcisi ve bir yürütme istemcisi çalıştırır. Bugün itibariyle, hiçbir mutabakat veya yürütme istemcisi ağın 2/3'ünden fazlasını oluşturmamaktadır. Kategorisinde 1/3'ten daha az paya sahip bir istemcide hata varsa, ağ normal şekilde devam edecektir. Kategorisinde 1/3 ile 2/3 arasında paya sahip bir istemcide (yani, Prysm, Lighthouse veya Geth) bir hata varsa, zincir blok eklemeye devam edecek, ancak blokları sonlandırmayı durduracak ve geliştiricilere müdahale etmeleri için zaman verecektir.

Ethereum zincirinin doğrulanma biçiminde yeterince tartışılmayan, ancak yine de çok önemli, yaklaşmakta olan büyük bir geçiş, ZK-EVM'lerin yükselişidir. EVM uygulamasını kanıtlayan SNARK 'lar zaten yıllardır geliştirilmektedir ve teknoloji, ZK rollup'ları adı verilen katman 2 protokolleri tarafından aktif olarak kullanılmaktadır. Bu ZK toplamalarından bazıları bugün ana ağda aktiftir ve yakında daha fazlası gelecektir . Ancak uzun vadede, ZK-EVM'ler sadece rollup'lar için olmayacak; bunları 1. katmanda yürütmeyi doğrulamak için de kullanmak istiyoruz (ayrıca bkz: the Verge).

Bu gerçekleştiğinde, ZK-EVM'ler fiilen üçüncü bir Ethereum istemcisi türü haline gelir ve ağın güvenliği için bugün yürütme istemcileri ve mutabakat istemcileri kadar önemlidir. Bu da doğal olarak bir soruyu gündeme getiriyor: ZK-EVM'ler çoklu istemci felsefesiyle nasıl etkileşime girecek? Zor kısımlardan biri zaten yapıldı: aktif olarak geliştirilmekte olan birden fazla ZK-EVM uygulamamız var. Ancak diğer zor kısımlar devam ediyor: Ethereum bloklarının doğruluğunu ZK ile kanıtlamak için "çok istemcili" bir ekosistemi nasıl oluşturacağız? Bu soru bazı ilginç teknik zorlukları ve tabii ki ödün vermeye değip değmeyeceği sorusunu da beraberinde getiriyor.

Ethereum'un çoklu istemci felsefesinin asıl motivasyonu neydi?

Ethereum'un çoklu istemci felsefesi bir tür ademi merkeziyetçiliktir ve <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> genel olarak ademi merkeziyetçilik gibi, mimari ademi merkeziyetçiliğin teknik faydalarına ya da siyasi ademi merkeziyetçiliğin sosyal faydalarına odaklanılabilir. Nihayetinde, çok müşterili felsefe her ikisi tarafından motive edilmiş ve her ikisine de hizmet etmektedir.

Teknik ademi merkeziyetçilik için argümanlar

Teknik ademi merkeziyetçiliğin ana faydası basittir: tek bir yazılım parçasındaki bir hatanın tüm ağda feci bir çöküşe yol açma riskini azaltır. Bu riski örnekleyen tarihsel bir durum 2010 Bitcoin taşma hatasıdır. O dönemde Bitcoin istemci kodu, bir işlemin çıktılarının toplamının taşmadığını (^264-1maksimum tamsayısının üzerine çıkarak sıfıra sarmadığını) kontrol etmiyordu ve bu nedenle birisi tam olarak bunu yapan bir işlem yaparak kendisine milyarlarca bitcoin verdi. Hata saatler içinde keşfedildi ve aceleyle bir düzeltme yapıldı ve hızla ağa dağıtıldı, ancak o sırada olgun bir ekosistem olsaydı, bu madeni paralar borsalar, köprüler ve diğer yapılar tarafından kabul edilecekti ve saldırganlar çok para kazanabilirdi. Beş farklı Bitcoin istemcisi olsaydı, hepsinin aynı hataya sahip olması pek olası olmazdı ve bu nedenle ani bir bölünme olurdu ve bölünmenin hatalı olan tarafı muhtemelen kaybederdi.

Felaket hataları riskini en aza indirmek için çoklu istemci yaklaşımının kullanılmasında bir değiş tokuş vardır: bunun yerine, konsensüs hatası hataları elde edersiniz. Yani, iki müşteriniz varsa, müşterilerin bazı protokol kurallarını ince bir şekilde farklı yorumlama riski vardır ve her iki yorum da makul olsa ve para çalmaya izin vermese de, anlaşmazlık zincirin ikiye bölünmesine neden olabilir. Ethereum'un tarihinde bu türden ciddi bir bölünme bir kez yaşandı (kodun eski sürümlerini çalıştıran ağın çok küçük bölümlerinin çatallandığı çok daha küçük bölünmeler de oldu). Tek istemci yaklaşımının savunucuları, birden fazla uygulamaya sahip olmamak için bir neden olarak mutabakat başarısızlıklarına işaret etmektedir: yalnızca bir istemci varsa, bu tek istemci kendisiyle aynı fikirde olmayacaktır. Müşteri sayısının riske nasıl dönüştüğüne dair modelleri şöyle görünebilir:

Elbette ben bu analize katılmıyorum. Benim anlaşmazlığımın özü, (i) 2010 tarzı yıkıcı hataların da önemli olduğu ve (ii) aslında hiçbir zaman sadece bir müşteriniz olmadığıdır. İkinci nokta 2013'teki Bitcoin çatallanmasıyla daha da belirgin hale gelmiştir: Bitcoin istemcisinin iki farklı sürümü arasındaki anlaşmazlık nedeniyle zincir bölünmesi meydana gelmiş ve bu sürümlerden birinin tek bir blokta değiştirilebilecek nesne sayısında kazara ve belgelenmemiş bir sınıra sahip olduğu ortaya çıkmıştır. Dolayısıyla, teoride bir müşteri pratikte genellikle iki müşteridir ve teoride beş müşteri pratikte altı ya da yedi müşteri olabilir - bu yüzden risk eğrisinin sağ tarafına geçmeli ve en azından birkaç farklı müşteriye sahip olmalıyız.

Siyasi adem-i merkeziyetçilik için argümanlar

Tekel müşteri geliştiricileri çok fazla siyasi güce sahip bir konumdadır. Bir istemci geliştiricisi bir değişiklik önerirse ve kullanıcılar buna katılmazsa, teorik olarak güncellenmiş sürümü indirmeyi reddedebilir veya bu değişiklik olmadan bir çatal oluşturabilirler, ancak pratikte kullanıcıların bunu yapması genellikle zordur. Ya hoş olmayan bir protokol değişikliği gerekli bir güvenlik güncellemesiyle birlikte gelirse? Ya ana ekip istediklerini alamazlarsa işi bırakmakla tehdit ederse? Ya da daha yumuşak bir ifadeyle, tekel konumundaki müşteri ekibi en büyük protokol uzmanlığına sahip tek grup haline gelirse, ekosistemin geri kalanını müşteri ekibinin öne sürdüğü teknik argümanları değerlendirmek için zayıf bir konumda bırakırsa ve müşteri ekibine daha geniş toplulukla uyuşmayabilecek kendi özel hedeflerini ve değerlerini zorlamak için çok fazla alan bırakırsa ne olur?

Özellikle bazı katılımcıların açıkça zincirin belirli kullanımlarına karşı ayrımcılık yapmaktan yana olduğu 2013-14 Bitcoin OP_RETURN savaşları bağlamında protokol politikalarına ilişkin endişe, Ethereum'un küçük bir grubun bu tür kararlar almasını zorlaştırmayı amaçlayan çoklu istemci felsefesini erken benimsemesinde önemli bir etken olmuştur. Ethereum ekosistemine özgü endişeler - yani Ethereum Vakfı'nın kendi içinde güç yoğunlaşmasından kaçınmak - bu yöne daha fazla destek sağladı. 2018 yılında, Vakfın Ethereum PoS protokolünün bir uygulamasını kasıtlı olarak yapmamasına karar verildi (örn. "mutabakat müşterisi" olarak adlandırılan), bu görevi tamamen dış ekiplere bırakmıştır.

ZK-EVM'ler gelecekte 1. katmanda nasıl yer alacak?

Günümüzde ZK-EVM'ler rollup'larda kullanılmaktadır. Bu, pahalı EVM uygulamasının zincir dışında yalnızca birkaç kez gerçekleşmesine izin vererek ölçeklendirmeyi artırır ve diğer herkes sadece EVM uygulamasının doğru hesaplandığını kanıtlayan zincir üzerinde yayınlanan SNARK 'ları doğrular. Ayrıca bazı verilerin (özellikle imzaların) zincire dahil edilmemesini sağlayarak gaz maliyetlerinden tasarruf sağlar. Bu bize birçok ölçeklenebilirlik avantajı sağlar ve ZK-EVM'lerle ölçeklenebilir hesaplama ve <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> data availability sampling ile ölçeklenebilir veri kombinasyonu çok ileri ölçeklendirmemizi sağlayabilir.

Bununla birlikte, Ethereum ağının bugün farklı bir sorunu daha vardır ve bu sorun hiçbir 2. katman ölçeklendirmesinin tek başına çözemeyeceği bir sorundur: 1. katmanın doğrulanması, pek çok kullanıcının kendi düğümünü çalıştırmadığı noktaya kadar zordur. Bunun yerine, çoğu kullanıcı üçüncü taraf sağlayıcılara güvenmektedir. Helios ve Succinct gibi hafif istemciler sorunu çözmeye yönelik adımlar atmaktadır, ancak hafif bir istemci tam bir doğrulama düğümü olmaktan uzaktır: hafif bir istemci yalnızca senkronizasyon komitesi adı verilen rastgele bir doğrulayıcı alt kümesinin imzalarını doğrular ve zincirin gerçekten protokol kurallarına uyduğunu doğrulamaz. Bizi, kullanıcıların zincirin kurallara uyduğunu gerçekten doğrulayabileceği bir dünyaya getirmek için farklı bir şey yapmamız gerekir.

Seçenek 1: 1. katmanı daraltın, neredeyse tüm faaliyeti 2. katmana geçmeye zorlayın

Zaman içinde blok başına 1. katman gaz hedefini 15 milyondan 1 milyona düşürebiliriz, bu da bir bloğun tek bir SNARK ve birkaç para yatırma ve çekme işlemi içermesi için yeterlidir, ancak başka bir şey içermez ve böylece neredeyse tüm kullanıcı faaliyetlerini 2. katman protokollerine geçmeye zorlayabiliriz. Böyle bir tasarım yine de her blokta işlenen birçok toplamayı destekleyebilir: birden fazla katman 2 protokolünden SNARK'ları bir araya getirmek ve bunları tek bir SNARK'ta birleştirmek için özelleştirilmiş oluşturucular tarafından çalıştırılan zincir dışı toplama protokollerini kullanabiliriz. Böyle bir dünyada, katman 1'in tek işlevi katman 2 protokolleri için bir takas odası olmak, kanıtlarını doğrulamak ve zaman zaman aralarında büyük fon transferlerini kolaylaştırmak olacaktır.

Bu yaklaşım işe yarayabilir, ancak birkaç önemli zayıflığı vardır:

• Fiili olarak geriye dönük uyumsuzdur, bu da mevcut birçok L1 tabanlı uygulamanın ekonomik olarak yaşayamaz hale gelmesi anlamına gelir. Yüzlerce veya binlerce dolara varan kullanıcı fonları, ücretler bu hesapları boşaltma maliyetini aşacak kadar yükseldiğinde sıkışıp kalabilir. Bu sorun, kullanıcıların protokol içi bir toplu geçişi kendi seçtikleri bir L2'ye tercih etmeleri için mesaj imzalamalarına izin verilerek çözülebilir ( buradaki bazı erken uygulama fikirlerine bakın), ancak bu geçişe karmaşıklık katar ve bunu gerçekten yeterince ucuz hale getirmek zaten katman 1'de bir tür SNARK gerektirecektir. Genellikle <a href="https://hackmd.io/@vbuterin/selfdestruct"> SELFDESTRUCT işlem kodu gibi şeyler söz konusu olduğunda geriye dönük uyumluluğu bozma taraftarıyım, ancak bu durumda değiş tokuş çok daha az elverişli görünüyor.
• Yine de doğrulamayı yeterince ucuz yapmayabilir. İdeal olarak, Ethereum protokolünün yalnızca dizüstü bilgisayarlarda değil, aynı zamanda telefonlarda, tarayıcı uzantılarında ve hatta diğer zincirlerde de doğrulanması kolay olmalıdır. Zinciri ilk kez veya uzun bir süre çevrimdışı kaldıktan sonra senkronize etmek de kolay olmalıdır. Bir dizüstü bilgisayar düğümü 1 milyon gazı ~20 ms'de doğrulayabilir, ancak bu bile bir gün çevrimdışı olduktan sonra senkronizasyon için 54 saniye anlamına gelir ( <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality"> single slot finality slot sürelerini 32s'ye çıkarır) ve telefonlar veya tarayıcı uzantıları için blok başına birkaç yüz milisaniye sürer ve yine de ihmal edilemeyecek bir pil tüketimi olabilir. Bu rakamlar idare edilebilir, ancak ideal değildir.
• L2 öncelikli bir ekosistemde bile, L1'in en azından biraz uygun fiyatlı olmasının faydaları vardır. Kullanıcılar yeni durum verilerinin artık sunulmadığını fark ettiklerinde fonlarını geri çekebilirlerse Validiumlar daha güçlü bir güvenlik modelinden faydalanabilir. Arbitraj, özellikle daha küçük tokenlar için, ekonomik olarak uygulanabilir bir çapraz L2 doğrudan transferinin minimum boyutu daha küçükse daha verimli hale gelir.

Bu nedenle, 1. katmanın kendisini doğrulamak için ZK-SNARK'ları kullanmanın bir yolunu bulmaya çalışmak daha makul görünmektedir.

Seçenek 2: SNARK-katman 1'i doğrulayın

Bir (katman 1) Ethereum bloğunun EVM yürütmesini doğrulamak için tip 1 (tamamen Eth ereum eşdeğeri) bir ZK-EVM kullanılabilir. Bir bloğun mutabakat tarafını da doğrulamak için daha fazla SNARK kodu yazabiliriz. Bu zorlu bir mühendislik problemi olacaktır: günümüzde ZK-EVM'lerin Ethereum bloklarını doğrulaması dakikalar ila saatler sürmektedir ve gerçek zamanlı olarak ispat üretmek için (i) SNARK dostu olmayan bileşenleri kaldırmak için Ethereum'un kendisinde iyileştirmeler, (ii) özel donanımla büyük verimlilik kazanımları ve (iii) çok daha fazla paralelleştirme ile mimari iyileştirmelerden biri veya daha fazlası gerekecektir. Bununla birlikte, bunun yapılamaması için temel bir teknolojik neden yok - ve bu nedenle, uzun yıllar alsa bile, yapılacağını umuyorum.

Burada çoklu istemci paradigmasıyla kesişen noktayı görüyoruz: 1. katmanı doğrulamak için ZK-EVM'leri kullanırsak, hangi ZK-EVM'yi kullanacağız?

Üç seçenek görüyorum:

1. Tek ZK-EVM: Çok istemcili paradigmayı terk edin ve blokları doğrulamak için kullandığımız tek bir ZK-EVM seçin.
2. Kapalı çoklu ZK-EVM: belirli bir çoklu ZK-EVM kümesi üzerinde mutabık kalın ve mutabakata dahil edin ve bir bloğun geçerli sayılması için bu kümedeki ZK-EVM'lerin yarısından fazlasının kanıtlarına ihtiyaç duyduğuna dair bir mutabakat katmanı protokol kuralına sahip olun.
3. Açık çoklu ZK-EVM: farklı istemciler farklı ZK-EVM uygulamalarına sahiptir ve her istemci bir bloğu geçerli olarak kabul etmeden önce kendi uygulamasıyla uyumlu bir kanıt bekler.

Bana göre (3) ideal görünüyor, en azından teknolojimiz tüm ZK-EVM uygulamalarının birbirine eşdeğer olduğunu resmi olarak kanıtlayabileceğimiz noktaya kadar gelişene kadar, bu noktada hangisi en verimli ise onu seçebiliriz. (1) çoklu müşteri paradigmasının faydalarını feda edecek ve (2) yeni müşteriler geliştirme olasılığını kapatacak ve daha merkezi bir ekosisteme yol açacaktır. (3)'ün zorlukları var, ancak bu zorluklar en azından şimdilik diğer iki seçeneğin zorluklarından daha küçük görünüyor.

(3)'ü uygulamak çok zor olmayacaktır: her kanıt türü için bir p2p alt ağı olabilir ve bir kanıt türünü kullanan bir istemci ilgili alt ağı dinler ve doğrulayıcısının geçerli olarak kabul ettiği bir kanıt alana kadar bekler.

(3)'ün iki ana zorluğu muhtemelen şunlardır:

• Gecikme sorunu: Kötü niyetli bir saldırgan, bir istemci için geçerli bir kanıtla birlikte bir bloğu geç yayınlayabilir. Diğer istemciler için geçerli kanıtlar üretmek gerçekçi olarak uzun zaman alacaktır (örneğin 15 saniye olsa bile). Bu süre, potansiyel olarak geçici bir çatal oluşturmak ve zinciri birkaç slot için bozmak için yeterince uzun olacaktır.
• Veri verimsizliği: ZK-SNARK'ların bir faydası, yalnızca doğrulama ile ilgili olan verilerin (bazen "tanık verileri" olarak adlandırılır) bir bloktan çıkarılabilmesidir. Örneğin, bir imzayı doğruladıktan sonra, imzayı bir blokta tutmanıza gerek yoktur, sadece imzanın geçerli olduğunu söyleyen tek bir biti ve blokta tüm geçerli imzaların var olduğunu onaylayan tek bir kanıtı saklayabilirsiniz. Ancak, bir blok için birden fazla türde kanıt üretmenin mümkün olmasını istiyorsak, orijinal imzaların gerçekten yayınlanması gerekecektir.

Gecikme sorunu, tek yuvalı sonlandırma protokolü tasarlanırken dikkatli olunarak ele alınabilir. Tek yuvalı kesinlik protokolleri muhtemelen yuva başına ikiden fazla mutabakat turu gerektirecektir ve bu nedenle ilk turun bloğu içermesi ve yalnızca düğümlerin üçüncü (veya son) turda imzalamadan önce kanıtları doğrulaması gerekebilir. Bu, bir bloğun yayınlanması için son tarih ile provaların hazır olmasının beklendiği zaman arasında her zaman önemli bir zaman aralığının mevcut olmasını sağlar.

Veri verimliliği sorunu, doğrulama ile ilgili verilerin toplanması için ayrı bir protokolün olmasıyla ele alınmalıdır. İmzalar için ERC-4337'nin halihazırda desteklediği BLS toplam asını kullanabiliriz. Doğrulama ile ilgili verilerin bir diğer önemli kategorisi de gizlilik için kullanılan ZK-SNARK'lardır. Neyse ki, bunlar genellikle kendi toplama protokollerine sahip olma eğilimindedir.

SNARK'ın 1. katmanı doğrulamasının önemli bir faydası olduğunu da belirtmek gerekir: zincir üzerinde EVM uygulamasının artık her düğüm tarafından doğrulanmasına gerek olmaması, gerçekleşen EVM uygulaması miktarını büyük ölçüde artırmayı mümkün kılmaktadır. Bu, ya 1. katman gaz limitinin büyük ölçüde artırılmasıyla, ya da enshrined rollup'ların getirilmesiyle ya da her ikisiyle birden gerçekleşebilir.

Sonuçlar

Açık, çok istemcili bir ZK-EVM ekosisteminin iyi çalışmasını sağlamak çok fazla çalışma gerektirecektir. Ancak gerçekten iyi haber şu ki, bu çalışmaların çoğu zaten yapılıyor ya da yapılacak:

• Halihazırda birden fazla güçlü ZK-EVM uygulamamız var. Bu uygulamalar henüz tip 1 (tamamen Ethereum eşdeğeri) değildir, ancak birçoğu aktif olarak bu yönde ilerlemektedir.
• Helios ve Succinct gibi hafif istemciler üzerindeki çalışmalar, sonunda Ethereum zincirinin PoS konsensüs tarafının daha eksiksiz bir SNARK doğrulamasına dönüşebilir.
• Özellikle durumsuz istemcilerimiz olduğunda ve durumu korumak için her bloğu doğrudan yeniden yürütmek için teknik bir ihtiyaç olmadığında, istemciler Ethereum blok yürütmesini kendi başlarına kanıtlamak için ZK-EVM'leri denemeye başlayacaktır. Muhtemelen Ethereum bloklarını yeniden çalıştırarak doğrulayan istemcilerden, SNARK kanıtlarını kontrol ederek Ethereum bloklarını doğrulayan çoğu istemciye yavaş ve kademeli bir geçiş yapacağız.
• ERC-4337 ve PBS ekosistemlerinin, gaz maliyetlerinden tasarruf etmek için çok yakında BLS ve kanıt toplama gibi toplama teknolojileriyle çalışmaya başlaması muhtemeldir. BLS toplama konusunda çalışmalar çoktan başlamıştır.

Bu teknolojiler mevcutken, gelecek çok iyi görünüyor. Ethereum blokları bugünkünden daha küçük olacak, herkes dizüstü bilgisayarında, hatta telefonunda veya bir tarayıcı uzantısında tamamen doğrulayıcı bir düğüm çalıştırabilecek ve tüm bunlar Ethereum'un çoklu istemci felsefesinin faydaları korunarak gerçekleşecektir.

Uzun vadeli gelecekte elbette her şey olabilir. Belki de yapay zeka, ZK-EVM uygulamalarının eşdeğer olduğunu kolayca kanıtlayabileceği ve aralarındaki farklara neden olan tüm hataları belirleyebileceği noktaya kadar resmi doğrulamayı süper şarj edecektir. Böyle bir proje, üzerinde şimdi çalışmaya başlamak için pratik olabilecek bir şey bile olabilir. Bu tür resmi doğrulamaya dayalı bir yaklaşımın başarılı olması halinde, protokolün siyasi ademi merkeziyetçiliğinin devam etmesini sağlamak için farklı mekanizmaların devreye sokulması gerekecektir; belki de bu noktada protokol "tamamlanmış" olarak kabul edilecek ve değişmezlik normları daha güçlü olacaktır. Ancak uzun vadeli gelecek bu olsa bile, açık çok müşterili ZK-EVM dünyası her halükarda gerçekleşmesi muhtemel doğal bir atlama taşı gibi görünüyor.

Yakın vadede, bu hala uzun bir yolculuk. ZK-EVM'ler burada, ancak ZK-EVM'lerin katman 1'de gerçekten uygulanabilir hale gelmesi için tip 1 olmaları ve gerçek zamanlı olarak gerçekleşebilecek kadar hızlı kanıtlama yapmaları gerekir. Yeterli paralelleştirme ile bu yapılabilir, ancak yine de oraya ulaşmak için çok çalışmak gerekecektir. KECCAK, SHA256 ve diğer hash fonksiyonu ön derlemelerinin gaz maliyetini yükseltmek gibi mutabakat değişiklikleri de resmin önemli bir parçası olacaktır. Bununla birlikte, geçişin ilk adımları beklediğimizden daha erken gerçekleşebilir: Verkle ağaçlarına ve durumsuz istemcilere geçtiğimizde, istemciler yavaş yavaş ZK-EVM'leri kullanmaya başlayabilir ve "açık çoklu ZK-EVM" dünyasına geçiş kendiliğinden gerçekleşmeye başlayabilir.

Sorumluluk Reddi：

1. Bu makale[vitalik]'ten yeniden basılmıştır, Tüm telif hakları orijinal yazar[vitalik]'e aittir. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.