tl;dr
- L2'ler, temel aldıkları L1'lerle aynı sansür direncine sahip olmalıdır
- BOB'da kullanıcılar varlıklarını bir Ethereum işlemi aracılığıyla BOB'dan Ethereum'a çekmeye zaten zorlayabilirler
- BOB, BitVM köprüsü için, kullanıcıların BOB üzerinde işlem yapmalarını sağlamanın bir yolu olarak Bitcoin'i entegre etmek için çalışıyor
- Bitcoin kullanıcıları BOB'a bir işlem göndermek zorunda kalmadan BTC'lerini BOB'dan çekebilecekler
L2'lerin temel özelliklerinden biri, sıralayıcı çevrimdışı olduğunda bile durumlarının ilerlemesi gerektiğidir. L2'ler bunu, L2'nin çevrimiçi olmasından bağımsız olarak güncellenebilen bir Veri Kullanılabilirliği (DA) katmanından durumlarını okuyarak ve yazarak başarır. Bu şekilde kullanıcılar, sıralayıcı çevrimdışı olduğunda veya sıralayıcı işlemlerini doğrudan kabul etmediğinde bile işlemlerinin dahil edilmesini zorlayabilirler.
BOB'un BitVM köprüsü için bu ilginç bir sorun teşkil etmektedir. BOB şu anda DA katmanı olarak Ethereum EIP-4844 bloblarını kullanmaktadır. Ethereum'daki kullanıcılar, BitVM köprüsü aracılığıyla Bitcoin'e geri çekme işlemlerini kolayca tetikleyebilir. Ancak, kullanıcıların Ethereum üzerinde ETH'ye sahip olmalarını gerektirir.
Bu bizim için yeterince iyi değil: Bitcoin kullanıcıları BTC'lerini BOB'dan Bitcoin'e geri çekmeye zorlamak için yalnızca Bitcoin'de BTC'ye ihtiyaç duymalıdır. Hibrit bir çözüm üzerinde çalışıyoruz: DA olarak Ethereum'u varsayılan hale getirirken, kullanıcıların Bitcoin'deki özel bir işlem aracılığıyla BOB'daki işlemleri dahil etmeye zorlamalarına izin vermek. Bu blog yazısında devam eden çalışmalarımızı paylaşmaktan heyecan duyuyoruz.
DA ve Türetme Üzerine Bir Arka Plan
Türetme süreci L2'ler için oldukça önemlidir: BOB'un tüm L2 durumunun L1 ve DA katmanından inşa edilmesi gerekir. Bu, L2'lerin DA katmanıyla, bizim durumumuzda Ethereum ile aynı sansür direncine sahip olmasını sağlar.
Basitleştirirsek, rollup'larda (özellikle OP Stack zincirlerinde), L1 üzerinde iki tür verimiz vardır:
- Para yatırma işlemleri "OptimismPortal" sözleşmesine yapılmıştır. Bunlar, Ethereum'daki kullanıcılar tarafından genellikle varlıklarını BOB'a yatırmak için yapılan işlemlerdir. Bu para yatırma işlemleri BOB üzerinde başka işlemler gerçekleştirmek için de kullanılabilir.
- Sıralayıcı (veya daha kesin olmak gerekirse op-batcher) tarafından L2 işlemlerinden gönderilen gruplar. Bunlar, kullanıcılar tarafından doğrudan BOB üzerinde yapılan tüm işlemleri içerir ve sonunda Ethereum bloblarına geri dahil edilir.
DA Katmanı olarak Bitcoin
Bitcoin'i bir DA katmanı olarak istiyorsak, neden Bitcoin'i tamamen bir DA katmanı olarak kullanmaya geçmeyelim? Cevap çoğunlukla maliyettir. Bitcoin çok az depolama alanına sahiptir (kabaca her 10 dakikada bir yaklaşık 4MB) ve bu nedenle depolama maliyeti yüksektir.
Ancak bizim durumumuzda BOB, Ethereum'u tüm işlem verilerini gönderdiği "ana" DA katmanı olarak kullanmaya devam edebilir, ancak Ethereum DA'nın kullanılamaması durumunda Bitcoin'i sansüre karşı oldukça dirençli bir yedek katman olarak ekleyebilir. Esasen, Ethereum iyimser DA katmanı haline gelirken, Bitcoin pahalı ancak hataya dayanıklı son çare haline gelir.
Hibrit Türetme Boru Hattı
Temel çözüm, Bitcoin'i BOB'a türetme işlem hattının bir parçası olarak eklemektir; böylece BOB (ve özellikle "op-node") girdileri bu sırayla işler:
- Bitcoin zorunlu para çekme işlemleri (BOB için özel olarak yeni eklendi)
- BOB'un OptimismPortal sözleşmesine Ethereum yatırımı (OP Stack standardı)
- Op-batcher'dan Ethereum partileri (OP Stack standardı)
Bitcoin'in zorunlu para çekme işlemlerini BOB türetme hattına kodlamak için olası bir çözüme geçelim. Bunun hala araştırılmakta olduğunu, bu nedenle değişikliklerin mümkün olduğunu unutmayın.
Bitcoin Zorla Para Çekme İşlemleri
Zorunlu para çekme işlemi oluşturmak için üç parçaya ihtiyacımız olacak:
- Bitcoin'de zorunlu para çekme işlemini oluşturun.
- Zorunlu para çekme işlemini Bitcoin'in boyut sınırları dahilinde Bitcoin'de saklayın.
- Bitcoin'de zorunlu para çekme işlemi için gaz maliyetlerini karşılayın.
1. Zorla Para Çekme İşlemini Oluşturun
Bir OP yığın para yatırma işlemi aşağıdaki yapıya sahiptir:
- bytes32 sourceHash: kaynak-hash, depozitonun kaynağını benzersiz bir şekilde tanımlar.
- adres kimden: Gönderen hesabının adresi.
- address to: Alıcı hesabın adresi veya yatırılan işlem bir sözleşme oluşturma ise null (sıfır uzunluklu) adres.
- uint256 mint: L2 üzerinde basılacak ETH değeri.
- uint256 değer: Alıcı hesabına gönderilecek ETH değeri.
- uint64 gaz: L2 işlemi için gaz limiti.
- bool isSystemTx: True ise, işlem L2 blok gaz havuzu ile etkileşime girmez.
- bayt veri: Çağrı verileri.
Zorunlu bir para çekme işlemi, kodlanmış para çekme işleminin para yatırma işleminin veri alanına dahil edilmesini gerektirir. Bu, BOB'dan Bitcoin'e para çekme işlemini tetikleyen ve işlemin Ethereum'dan gönderilmesiyle tamamen aynı şekilde çalışacak olan işlemi BOB'da oluşturarak yapılır.
Daha sonra Bitcoin'de yukarıdaki tüm verileri içeren zorunlu para çekme işleminin (sıkıştırılmış) bir versiyonunu saklayabiliriz.
2. Zorla Para Çekme İşlemini Bitcoin'de Saklayın
Zorunlu para çekme işlemine ilişkin veriler, OP_RETURN çıktısında depolanması gerekenden daha büyük olduğundan, verileri depolamak için muhtemelen bir Taproot çıktısı kullanacağız.
BOB'un OptimismPortal sözleşmesine gönderilmesi nedeniyle Ethereum'da bir para yatırma işlemini (para çekme içerebilir) tanımlamak kolay olsa da, Bitcoin'de zorunlu bir para çekme işlemini tanımlamak o kadar kolay değildir.
Veri Serileştirme: Zorunlu para çekme işlemi, bir "zarf" yapısı içinde Taproot komut dosyaları kullanılarak serileştirilir. Bunlar Bitcoin ağındaki noops'lardır ve örneğin Ordinals için de kullanılır. Yapıyı ihtiyaçlarımıza uyacak şekilde ayarlıyoruz.
Ayarlanmamış
OP_FALSE OP_IF
OP_PUSH "bob"
OP_1
OP_PUSH "işlem"
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
İki Aşamalı Taahhüt/Reveal Şeması:
Ordinals'ta olduğu gibi, kullanıcıların Bitcoin'e iki işlem göndermesi gerekecek:
- Taahhüt İşlemi: Yazıt içeriğini içeren komut dosyasına işleyen bir Taproot çıktısı oluşturur. Bu işlem henüz verileri ortaya çıkarmaz ve BOB tam düğümleri ve sıralayıcıların geri çekme işlemini içermesi için ikinci işleme ihtiyacımız olacaktır.
- İşlemi Ortaya Çıkarır: Taahhüt işleminden elde edilen çıktıyı harcayarak zincir üzerindeki yazıyı açığa çıkarır, yani kullanıcının para çekme işlemini BOB'a dahil edilmek üzere açığa çıkarır.
3. Zorla Geri Çekme İşlemi için Gaz Maliyetlerini Ele Alın
Bu, şu anda değerlendirilmekte olan iki seçenekle birlikte henüz en açık problemdir:
- Bitcoin'deki zorunlu para çekme işlemi için gazı 0 olarak ayarlayın ve gaz maliyetlerini kullanıcının BOB'daki ETH bakiyesinden düşürün. Bu şekilde, yalnızca BOB'da ETH'si olan kullanıcılar para çekmeye zorlayabilir. Ancak, bu iyi bir seçenek değildir çünkü kullanıcıların para çekmeye zorlamak için BOB'da ETH'ye sahip olmalarını gerektirir, yani Bitcoin'de BTC'ye sahip olan kullanıcılar para çekmeye zorlayamaz.
- Gaz, kullanıcılar tarafından Bitcoin'de BTC olarak ödenir. BOB ağının Bitcoin üzerinde BTC alabilecek bir adrese sahip olması ve gaz maliyetlerinin L1 kısmı artı yürütme maliyetlerini ödemek için kullanıcı tarafından alınan BTC'yi BOB üzerinde ETH ile etkin bir şekilde takas etmesi gerekecektir. Bu seçenek muhtemelen BOB Gateway kullanılarak ve BOB DAO'nun EVM adresi BTC alıcısı olarak ayarlanarak gerçekleştirilebilir.
Ayrıca daha fazla fikir deniyoruz, bu nedenle daha fazla güncelleme için bizi izlemeye devam edin!
Hepsini Bir Araya Getirmek
Herkes sadece Bitcoin ve Ethereum verilerini kontrol ederek BOB'un durumunu belirleyebilir:
- Bitcoin'den tüm para çekme işlemlerini okuyun. Bunlar her bir para çekme işlemi için iki işlem olarak kodlanır, yani bir taahhüt ve bir açığa çıkarma işlemi. Bu, OP Yığınına yaptığımız ve türetme boru hattını geliştirdiğimiz eklemedir.
- Ethereum'da BOB'un OptimismPortal sözleşmesine yapılan tüm işlemleri okuyun. Bu zaten standart OP Stack türetme hattının bir parçasıdır.
- Doğrudan BOB'da yapılan ve Ethereum'daki grupların bir parçası olarak entegre edilen tüm işlemleri okuyun. Daha da önemlisi, tam düğümler onaylanmış işlemleri almak için doğrudan sıralayıcıdan okuma yapmaz, Ethereum bloblarından okuma yapar. Bu zaten standart OP Stack türetme boru hattının bir parçasıdır.
Teknik Zorluklar
Veri Tutarlılığı: Ethereum ve Bitcoin zincirleri arasında veri tutarlılığının sağlanması önemli olmakla birlikte, işlem verilerinin her iki zincirde de bulunması geçerliliği garanti etmez. İşlemlerin meşru kabul edilebilmesi için rollup'ın durum geçiş fonksiyonuna göre geçerli durum geçişlerini temsil etmesi gerekir. Çözüm, bir işlemi kabul etmeden önce geçerli bir durum değişikliğiyle sonuçlanıp sonuçlanmadığını doğrulayan doğrulama mantığının op-node (veya diğer mutabakat katmanı uygulamaları) içinde uygulanmasını gerektirir.
Dolandırıcılık Kanıtları ve Geçerlilik: Hem BitVM hem de Ethereum için sahtekarlık kanıt sisteminin, her iki zincirden gelen verileri işlemek için geliştirilmesi gerekir, bu da anlaşmazlık çözümünü daha karmaşık hale getirebilir. Bunu ele almak için, BitVM köprüsünün ve BOB'un Ethereum'daki yerleşiminin bir parçası olarak Bitcoin ve Ethereum'dan olası işlemleri doğru bir şekilde hesaba katmamız gerekir.
Depolama Artışı: Ayrıca, ağdaki BOB düğümleri, Bitcoin ve Ethereum'dan gelen verileri işlemeleri ve depolamaları gerektiğinden artan depolama ve bant genişliği gereksinimleriyle karşı karşıyadır. Bununla birlikte, Bitcoin'de yapılan BOB işlemlerinin Ethereum bloblarına en son Bitcoin bloklarına referansla dahil edilmesini zorunlu tutarak bunu hafifletebiliriz. Bu şekilde, düğümlerin yalnızca son Bitcoin bloklarını senkronize etmesi gerekir.
Sonraki Adımlar
Bitcoin'in güvenliğini Ethereum'un inovasyonuyla birleştiren hibrit rollup'ların sınırlarını zorlamaktan heyecan duyuyoruz. Bu somut problemde, Bitcoin'in işlemlerin sansüre karşı direncini BOB'un rollup yığını ile birleştirmek istiyoruz. İlerleme kaydettikçe bu blog gönderisini daha fazla bilgi ile güncelleyeceğiz.
