Vitalik Buterin: Ethereum'da Casper Ceza Koşullarının Minimize Edilmesi
Geçen hafta Yoich, "ceza koşullarının en aza indirilmesi" sürecimi detaylandıran ve "ceza koşullarının en aza indirilmesi" ile sağlanan güvenlik ve canlılığı resmen gösteren bir blog yazısı yayınladı. Bu, Bizans hataya dayanıklı algoritmasının, eşzamansız güvenliğin ve kripto-ekonomik olarak mutabakat algoritmalarının önemli bir bileşenidir ve Bizans hataya dayanıklı algoritması, asenkron altında güvenli ve kriptoekonomik güvenlik mutabakat algoritmaları da haklarımdır. Yol haritasının özünü kanıtlayın. Bu yazıda, bu algoritmanın ne olduğunu, nerede önemli olduğunu ve genel olarak hakların ispatı araştırmalarına nasıl uygulandığını daha ayrıntılı olarak açıklamak istiyorum.
Casper'ın araştırmasının temel hedeflerinden biri, yarı biçimsel olarak şu şekilde tanımlanabilen "ekonomik kesinliğe" ulaşmaktır:
Bir müşteri (i) B1 bloğunun her zaman kanonik zincirin parçası olacağını kanıtlayabilirse veya (ii) B1 bloğunun geri yüklenmesine neden olan katılımcıların X dolar eşdeğeri tarafından cezalandırılacağının garanti edileceğini kanıtlayabilirse, bu durumda bu blok Ekonomide B1 kesinleşir ve kripto ekonomisindeki güvenlik marjı X dolar olur.
X'in yaklaşık olarak 70 milyon ABD dolarına eşit olduğunu düşünelim. Temel olarak, bir blok sonlandırılırsa, o zaman blok zincirin bir parçası olur ve bu gerçeği değiştirmek çok çok pahalıdır. İş kanıtı, aynı zamanda hakların kanıtlanmasının benzersiz bir özelliği olan bu etkiyi elde edemez. Niyetimiz% 51 saldırıları çok pahalı hale getirmektir ve doğrulayıcıların çoğu birlikte çalışsa bile, büyük bir ekonomik kayba uğramak istemedikçe belirlenen bloğu geri alamazlar - ekonomik kayıp çok büyük. Böylece saldırı başarılı olduğunda, bu, temeldeki kripto para biriminin fiyatını artıracaktır, çünkü piyasa, saldırıyı düzeltmek için acil bir hard fork sağlamak yerine, toplam madeni para arzındaki düşüşe güçlü bir şekilde tepki verecektir (temel felsefenin derinlemesine bir genel görünümü için buraya bakın) .
Casper çalışmasında ekonomik kesinlik, doğrulayıcıların katılım için bir depozito ödemelerini zorunlu kılarak tamamlandı ve anlaşma doğrulayıcıların bir dizi kuralı ihlal ettiğini belirlerse, doğrulayıcıların depozitoları alınacaktır (cezalar).
Ceza koşulu şu şekilde görünebilir:
Doğrulayıcı, bir formun imza bilgilerini gönderirse:
Bir formun imza bilgileri:
HASH1! = HASH2epoch_source1! = Epoch_source2epoch olduğunda
Protokol, bir dizi ceza koşulunu tanımlar. Dürüst doğrulama düğümleri, hiçbir koşulun tetiklenmemesini sağlamak için bir anlaşmayı takip eder. (Not: Bazen bir ceza koşulunu "ihlal" diyoruz. Eşanlamlısı "tetikleyicidir" ve ceza koşulunu şu şekilde ele alır: Bir yasa, yasayı ihlal etmemelisiniz). Dürüst bir doğrulama düğümü için hiç de zor olmayan bir HAZIRLAMA mesajını asla iki kez göndermeyin.
"PREPARE" ve "COMMIT", geleneksel Bizans hataya dayanıklı fikir birliği teorisinden ödünç alınmış terimlerdir. Şimdi, aşağıdaki protokol içeriğinde tanıtacağımız iki farklı mesaj türünü temsil ettiklerini varsayalım. Mutabakat anlaşmasının iki farklı anlaşma turu gerektirdiğini düşünebilirsiniz, burada PREPARE bir anlaşma turunu temsil eder ve COMMIT ikinci tur anlaşmayı temsil eder.
Aynı zamanda, başka bir deterministik koşul daha vardır, müşterinin bazı özel karma blokların kesin olduğundan emin olabildiğini açıkladı. Bunu anlamak kolaydır ve Casper çalışmasının mevcut versiyonundaki tek kesinliği ifade etmeye devam ediyoruz.
Bazı belirli dönemler bir dizi imzalı mesaj biçiminde saklanırsa, bir HASH belirlenir.
Bu imzalı e-postaları oluşturan doğrulayıcıların depozito bakiyelerini eklerseniz, elde ettiğiniz miktar mevcut aktif doğrulayıcı setinin toplam depozito bakiyesinin 2 / 3'ünden daha büyüktür.
Bir kısaltma olarak, "Hash, onaylayıcıların üçte ikisi tarafından belirli bir dönemde sunulur" veya "Hash'in belirli bir dönemde üçte ikisi garantilidir" diyebiliriz.
Ceza koşullarının aşağıdaki iki koşulu karşılaması gerekir:
Sorumluluğun güvenliği bize "ekonomik kesinlik" fikrini getirir. Eğer iki çelişen hash değeri doğrulanırsa (örneğin, çatallanma), o zaman geniş bir dizi doğrulamanın matematiksel bir kanıtı olur. Düğümler bazı ceza koşullarını ihlal etti. Bu kanıtı blok zincirine sunabilir ve ceza koşullarını ihlal eden doğrulama düğümlerini cezalandırabiliriz.
Makul canlılık, temel olarak "algoritmaların" takılıp kalmaması "ve hiçbir şeyi belirlememesi gerektiğini söyler.
Bu iki kavramın anlamını açıklığa kavuşturmak için iki oyuncak algoritmasını ele alabiliriz, biri güvenliği sağlayabilir ama canlılığı sağlayamaz, diğeri canlılığı tatmin edebilir ama güvenliği sağlayamaz.
Algoritma 1: Her doğrulayıcı düğümün bir COMMITCOMMIT biçimi gönderme şansı vardır
Burada, bu algoritmanın güvenli olduğuna dair açık bir kanıt var: HASH1 ve HASH2 onaylanırsa, iki karmanın her birinin sözün en az üçte ikisine sahip olduğu kanıtlanabilir, bu nedenle üç nokta olmalıdır. Örtüşmelerden biri meydana gelir, bu nedenle doğrulayıcı düğümlerin üçte biri kesilir (Eğik çizgi), ancak o hayatta değildir: eğer bir yarısı A'yı tamamlarsa, yarısı B'yi tamamlar ( Makul ölçüde olası kazalar), daha sonra onaylayıcı düğümlerin altıda biri bir karma değeri belirlemek için gönüllü olarak kendilerini parçalamalıdır.
(güvenlik doğrulaması)
Algoritma 2: Her doğrulama düğümünün COMMITepoch COMMIT bilgi listesini gönderme şansı vardır.
Bu, önceki algoritmadaki sorunu çözer.Aynı çağda 50/50, yarısı ve yarısı olduğu gibi, sonraki çağda tekrar deneyeceğiz, ancak bu başka bir güvenlik kusuru ortaya çıkarıyor: iki farklı ha Umut farklı dönemlerde tamamlanabilir.
Aynı anda iki hash almanın mümkün olduğu ortaya çıktı. Ancak bu önemsiz değil: Dört ceza koşulunun karşılanması gerekiyor, ayrıca Yoichi'nin gerçekten uygulanabilir olduğunu resmen kanıtlaması için tamamlaması gereken 1.000 satırlık kod.
Bu cezalar:
Belirli bir değer olmadıkça epoch_source-1 < = epoch_source < çağ
Bunlar doğrulayıcıların 2 / 3'ü tarafından imzalanıp yayınlanır ve doğrulayıcının depozitosu düşülür.
Basitçe İngilizce olarak ifade etmek gerekirse, bir istek göndermek için doğrulama düğümlerinin üçte ikisinin hazır olması gerekir.
Doğrulayıcı düğüm bir imza bilgileri listesi gönderirse:
Epoch_source! = -1epoch_source_source-1 olduğunda < = epoch_source_source < epoch_source
ANCESTOR_HASH (epoch poch_source)
Belirli bir dönemde belirli bir önceki dönemi belirtmek için önceden hazırlık yapmak istiyorsanız, o zaman onaylayıcıların üçte ikisinin bu süre içinde önceden hazırlanması ve bu hazırlıklar aynı önceki dönemi işaret etmelidir (örneğin, üçte ikisi 41. periyottaki doğrulama düğümlerinin 35. periyodu işaret etmesi normaldir. 41. periyottaki doğrulama düğümlerinin yalnızca yarısı 35. periyodu işaret etmeye, diğer yarısı ise 37. periyodu işaret etmeye hazırdır. Doğrulama düğümlerinin altıda beşinin periyotta olması imkansızdır. 41. Periyot hazırlanır, bunun beşte dördü 35. periyodu işaret eder, çünkü altıda beşin beşte dördü üçte ikidir, böylece kalan altıda birini görmezden gelebilirsiniz.
"N-inci derece ata" ("n-inci derece ata") blockchain hashing açısından ata anlamına gelir. Örneğin, Ethereum'un 3017225 bloğu bloktur 301724015. dereceden ata bloğu. Lütfen bir bloğun yalnızca bir ebeveyni olabileceğine, dolayısıyla belirli bir n sayısı için yalnızca bir n. Ata bulunduğuna dikkat edin.
Doğrulayıcı bir liste mesajı gönderirse
Bir hazırlık listesi bilgisi de var
Epoch_source < epoch1 < epoch2HASH1? = HASH2
Belli bir süre içinde bir sunum yaptığınızda, hazırlıkların üçte ikisinin bu dönemde gerçekleştiğini açıkça görebilirsiniz. Bu yüzden gelecekte hazırladığınız herhangi bir hazırlık, bu döneme veya yeni şeylere rehberlik etmek için daha iyi olmalıdır.
Doğrulayıcı bir mesaj listesi gönderirse
Bir bilgi listesi var
HASH1! = HASH2epoch_source1! = Epoch_source2 olduğunda
Tek bir dönemde iki kez hazırlık yapmak imkansızdır
Bu dört ceza koşulu sayesinde, makul faaliyet sağlanırken güvenilir güvenliğin sağlanmasının mümkün olduğu kanıtlanabilir.
Lütfen yukarıdaki kuralları kullanarak iki farklı karmanın nihai hale getirilebileceğini unutmayın - her iki karma da aynı tarih parçasının parçasıysa, o zaman nihai hale getirilebilir ve aslında Bu büyüyen zincirin sonunda sürekli olarak daha fazla karma belirlendiğinde, tam olarak istediğimiz şey budur.
Sol: Bu kuralları takip ederek farklı hash değerleri belirlenebilir, ancak hepsi aynı zincirin parçasıysa, beklendiği gibi davranacaktır. Sağ: Aynı tarihe ait olmayan hash'ler birbiriyle çatışır; Yukarıdaki dört ceza koşulunun, doğrulayıcıların en az üçte biri yenilmedikçe, sonuçlandırılacak iki çakışan hash düzenleyebileceğine dair kanıtlar vardır.
Şimdi bunları bir araya getirelim. Doğrulayıcılarla dolu bir havuz var (herkes serbestçe katılabilir, ancak bazı gecikmeler olmasına ve depozito yatırılması gerekmesine rağmen, elbette herhangi bir katılımcı daha yüksek bir gecikmeden sonra parasını çekip çekebilir) , Ve bu doğrulayıcılar liste bilgilerini imzalama ve gönderme hakkına sahiptir.
Belirli bir dönemde bu HASH için yeterli COMMIT mesajı varsa, bu HASH sonlandırılır. Karmalar birbiriyle bağlantılıdır ve her karma, önceki bazı karmalara işaret eder. Zaman arttıkça, eski ve büyüyen zincire daha fazla yeni eklemeler olduğunu görmeyi umuyoruz. Karmalar birbirine bağlanır ve sonlandırılır. Doğrulayıcıları, nihai tamamlamayı elde etmek için yeterli mesajı zamanında göndermeleri için HAZIRLIK ve BAŞVURU göndermeye teşvik etmek için finansal ödüller ekledik.
Genel olarak konuşursak, "senkronizasyon altında etkinliği garanti eden ve asenkron altında güvenliği garanti eden" Bizans hataya dayanıklı fikir birliği mekanizmasına sahip herhangi bir PBFT algoritmasını kullanabilirsiniz ve bunu size güvenilir güvenlik ve makullük sağlamak için bir dizi ceza koşullarına dönüştürür. Aktivite. Yukarıdaki koşulların tümü, Bizans Hata Toleransı (PBFT) ve Tendermint'in kombinasyonundan esinlenmiştir, ancak farklı sonuçlar üretebilecek başka noktalar da vardır.
Lütfen makul faaliyet ve fiili faaliyetin aynı şey olmadığını unutmayın; makul faaliyet, teorik olarak belirli şeyleri her zaman sonuçlandırabileceğimiz anlamına gelir, ancak her zaman böyle olabilir. Her zaman çok şanssızız, her zaman tekrarlıyoruz ve hiçbir şeyi belirlemek için asla bitmeyiz. Bu sorunu çözmek için bir bulmalıyız Teklif mekanizması Ve bu öneri mekanizmasının, aktifliğe ulaşmamıza gerçekten yardımcı olma amacına ulaşması gereken bu tür niteliklere sahip olmasını sağlamak için.
Teklif mekanizması, karmalar önermek için bir mekanizmadır ve geri kalanı, nihai hale getirmeyi tamamlamak için ellerinden gelenin en iyisini yapmak için COMMIT ve PREPARE mesajlarını kullanır. Bu mekanizma bazen kusurludur; yaptığı şey koşulları cezalandırmak için yapılması gereken şeydir, yani teklif mekanizması kusurlu olsa da, ona oy vermek de güvenliği etkili bir şekilde garanti edebilir ve teklif mekanizması durduğunda ve arızalandığında , Bu anlaşma, bu konuyu nihayet teyit edebilir.
Birçok geleneksel Bizans hataya dayanıklı fikir birliği mekanizması algoritmasında, öneri mekanizması ve algoritmanın diğer bölümleri yakından bağlantılıdır. Bizans hataya dayanıklı fikir birliği algoritmasında, her görünüm (kabaca bir döneme eşdeğer) tek bir doğrulayıcıya atanır ve bu doğrulayıcı, önermek istediklerini özgürce önerebilir. Bu doğrulayıcı, hiçbir şey önermeyebilir. Teklifler veya geçersiz karmalar önerin veya kötü işlemler üretmek için birden fazla karma önerin, ancak Bizans hataya dayanıklı mutabakat algoritmasının diğer bölümleri bu işlemlerin ölümcül olmayacağını garanti edecek ve bu algoritma otomatik olarak bir sonraki döneme geçecektir. . Burada ceza koşullarımızı, bazı koşulları yerine getirebildikleri sürece diğer birçok teklif mekanizmasıyla birleştirebiliriz.
Her şeyden önce, bu öneri mekanizması her periyotta yalnızca bir hash değeri önermelidir ve bu hash geçerli bir hash olmalıdır (geçerlilik koşulları çok karmaşık olabilir. Ethereum söz konusu olduğunda Ethereum şunları içerir: Ethereum halkasının durum geçiş işlevinin doğrulanması ve yürütülmesi ve tasarım verilerinin kullanılabilirliğinin doğrulama bağlantısı).
ikinci, Karmalar bir zincir oluşturmalıdır Yani, N periyodunda sunulan bir karma bir ebeveyne sahip olmalıdır, bu ebeveyn, N-1 periyodunda sunulan bir karma olmalıdır ve ikinci derece ata, N-2 periyodunda sunulan bir karma olmalıdır.
Üçüncüsü, hash bir hash olmalıdır ve ceza koşulu, doğrulayıcıların hash değerini nihayet belirlemesini engellemeyecektir. Bunun çok ince olduğu söylenebilir. Şimdi bir senaryo düşünelim. O periyodunda, teklif mekanizması hash 0'ı önerir ve 1. periyotta, teklif mekanizması sebep ne olursa olsun hash 1'i (hash 0'ın doğrudan alt hash'i) önerir. , Bu hash'lerin hiçbiri bir taahhüt almak için yeterince hazırlanmadı. Daha sonra, bu öneri mekanizması (bazı geçici hatalar nedeniyle) dönem 0 için başka bir hash 0 önerir, bu da hazırlığın üçte ikisini ve taahhütlerin yarısını gerektirir.
Şimdi, bu öneri mekanizması için iki seçenek var. İlk olasılık, HASH2 (HASH1'in alt karması), ardından HASH3 (HASH2'nin alt karması) ve benzerlerini önerebilmesidir. Bununla birlikte, ceza koşulu, doğrulayıcıların altıda biri yenilmezse hiçbir hash gönderilememesini sağlar. Diğer bir olasılık ve doğru olasılık, HASH1'i (HASH0'ın alt karması) sunması ve hash'in asla belirlenemeyeceğini beklemesi, çünkü rakibi HASH1'in hazırlıkların üçte birinden fazlasına sahip olması, bu nedenle HASH1, ihtiyaç duyduğu hazırlığın üçte ikisini alamaz ve ardından HASH2'yi (HASH1'in alt karması) önerir, HASH2 gönderilebilir ve daha sonra bu teklif mekanizması yeni karmalar ve her bir karma Önceki hash'in alt karmasıdır
Bazı kişilerin sahip olabileceği doğrudan bir fikir şudur: Geleneksel bir iş kanıtı zinciri oluşturabilir ve teklif mekanizması olarak en uzun zincirin kuralını izleyebilir miyiz? Her 100. blok, N * 100. bloğun karmasının, N periyodu için bir teklif haline geldiği bir kontrol noktasıdır. Ancak bu, bunun çalışmaya devam edebileceğini garanti etmez, çünkü yukarıdaki durumda, teklif mekanizması HASH1 yerine HASH2 göndermeye çalışacak, bu nedenle hiçbir hash sonlandırmayı tamamlamayacaktır ("takılı kaldı" dediğimiz şey bu değil, Çünkü bu durumdan kurtulmak için kimsenin kesilmesine gerek yoktur, ancak madencilerin HASH0 içeren zincir üzerinde birbirleriyle işbirliği yapmasını gerektirir, HASH1 içeren zincir iş kanıtında HASH0'dan daha uzun olsa bile) . Bununla birlikte, yapabileceğimiz şey, çatal seçimini değiştirebilen kurallarla birleştirilmiş geleneksel bir iş kanıtı blok zinciri kullanmaktır.
Çatal seçim kuralı bir işlevdir, bu işlev, giriş olarak oluşturulan blokların ve diğer mesajların koleksiyonunu alan ve müşteriye "standart zincir", "en uzun etkili" olan çıktıları alan müşteri değerlendirmesi tarafından oluşturulur. "Zincir doğru zincirdir" basit bir çatal seçim kuralıdır ve iş kanıtı için çok uygundur.Zohar ve Sompolinsky'nin GHOST'u daha karmaşık bir örnektir. Blok zincirinin bir fikir birliği mekanizması algoritması öneri mekanizması olarak kullanılmasına izin veren ve aşağıda gösterildiği gibi yukarıdaki özelliklere sahip bir çatallanma seçim kuralı tanımlayabiliriz:
Lütfen yukarıdaki örneğimizde bunun HASH1 yerine HASH0 için daha faydalı olacağını ve bu nedenle beklenen davranışa yol açacağını unutmayın. Ayrıca, son bir zincir varsa, her zaman son zinciri seçeceğini de lütfen unutmayın.
Yukarıdaki ceza kuralları, belirli bir arıza türünün çok pahalı olabileceğini garanti eder: çatalın son restorasyonu. Ancak aynı anda başka tür arızalar da olacaktır ve bu çatallar bu ceza kuralı ile çözülemez. Özellikle, geçersiz bir hash belirlemek ve geçersiz veri içeren bir zinciri temsil eden bir hash belirlemek için. Şu anda, mutlak şifreleme ekonomik güvenlik sorununu çözmenin en basit ve uygulanan yolu, tam bir düğüm indirme işlemi uygulamak ve tüm blokları doğrulamaktır, böylece geçersiz blokları tamamen göz ardı edebilirsiniz. Bu nedenle, bu hash'in sonlandırılıp sonlandırılmadığını belirlemek iki adımda yapılabilir: 1) Checker gönderimlerinin üçte ikisi ve 2) Hash'in geçerli olduğu kanıtlanana kadar zincir kontrol edilir.
Hafif müşteri için nihai değeri elde etmenin iki yolu vardır. İlk yol, bir mesaj göndermek için başka bir tür düğüm eklemektir. Bu, mesaj bir zincire gönderilirse ve içindeki karma aslında o dönemdeki karmadır, o zaman Bu doğrulayıcı ödülün bir kısmını alacak, eğer hash o dönemin hashi değilse, o zaman çok fazla ceza çekecekler. Bu nedenle, doğrulayıcı, yalnızca verilen karmanın müşteri tarafından görülen kanonik zincirin parçası olduğundan emin olduğunda bir mesaj gönderir ve sonsuza kadar yapmaya devam eder (doğrulayıcının bunu yapması için geçerli zaman, Bireyler blok zincirinden hash'e tam olarak doğruladıktan ve gönderimlerinin üçte ikisini kontrol ettikten sonra).
İkincisi, hafif istemcilere çeşitli şifreleme ekonomik teknolojilerine erişim sağlamaktır, böylece birkaç varsayım yardımıyla verilerin kullanılabilirliğini ve geçerliliğini çok etkili bir şekilde doğrulayabilirler. Bu, silme kodlarının ve etkileşimli doğrulamanın bir kombinasyonunu içerebilir. Bu, parçalama üzerine yapılan araştırmaya benzer ve ikisi arasındaki bağlantı çok yakındır - yukarıdaki ilk yöntem doğrulayıcının kendisinin tam bir düğüm olmasını gerektirirken, ikinci yöntem doğrulayıcının kendisini gerektirmez. Bu tam bir düğümdür ve parçalanmanın kendisi bir blok zinciri oluşturmakla ilgilidir.Bu blok zincirindeki hiçbir taraf tam bir düğüm değildir. Bu konudaki blog yazıları gelecekte güncellenmeye devam edecek.
Yoichi Hirai, Keefer Nehri ve Ed'e bu makaleyi incelememe yardımcı oldukları için özel teşekkürler.
Not:
1. Bazı insanlar iş ispatının ekonomik determinizm ve güvenlik marjı R * k olduğunu düşünebilir, burada R blok ödülü ve k geri yüklenen blok sayısıdır, ancak başarılı bir şekilde uygularsanız bu doğru değildir % 51 saldırı, o zaman blok ödülüyle telafi edilirsiniz -% 51 saldırısı için bütçe gereksinimi gerçekten kabaca R * k, ancak başarılı saldırınızın maliyeti 0'dır.
2. Üçte bir oran, geleneksel Bizans hata toleransı teorisinden alınmıştır ve toplam hata toleransı seviyesini en üst düzeye çıkarmak için seçilmiştir. Genel olarak, bu makalede herhangi bir t > 1/2 değeri, bu maddedeki üçte iki cezanın yerine geçer. Hata toleransını etkinlik perspektifinden 1-t olarak hesaplayabilirsiniz (çünkü çevrimdışı 1 t'yi aşarsanız, t'yi alamazsınız) ve güvenlik açısından hata toleransı 2t-1'dir (t nihayet A, t Sonunda B'yi belirleyebilir, sonra 2t'ye kadar ekleyebilir > 1, bu nedenle en az 2t-1 tekrarlanmalıdır). t = 2/3, ikisinin minimumunu maksimize eder (1-t = 1/3, 2t-1 = 1/3); ayrıca t = 3/5 deneyebilirsiniz (etkinlik: 2/5 hata toleransı , Güvenlik: 1/5) veya t = 3/4 (etkinlik: 1/4, güvenlik: 1/2). Lütfen t değerinin < 1/2, sağduyu altında kaç düğümün çevrimdışı olabileceği konusunda da mantıklı olacaktır, ancak bu durumları ve daha geniş "öznel kesinlik eşiği" kavramını çözerken, bir dahaki sefere başka bir makale yazacağım Makalede daha derinlemesine tartışılan başka bir konu.
3. Elbette bu depozitolar geri çekilmedikçe, ancak bu ("uzaktan saldırı") yazdığım başka bir makalenin konusu olacak, ancak bugünkü makalenin iki yıl önce yayınlanmış olması gerekirdi.
4. En azından, karma ve imza şifrelemesinin bir kombinasyonunu kullandığı sürece. Eşik imzaları kullanıyorsa, bu daha zor olacaktır. Çünkü 2/3 kötü niyetli düğümün ittifakı, diğer herhangi bir katılımcının imzasını taklit edebilir.
Gönderildiği andaki standart Bitcoin fiyatı Alış fiyatı: 8321,00 Satış fiyatı: 8145,00
Orijinal: https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c#.4s8pm7fu5
Yazar: Vitalik Buterin
Derleme: Lola
Makale kaynağı (çeviri): Babbitt Information ( Telif Hakkı Beyanı:
Yazar hakkını saklı tutar. Makale, yazarın bağımsız bakış açısıdır ve Babbitt'in görüşünü temsil etmez.
