MOVE dilinin ilk yakıt ücreti tasarımı: on-chain yakıt ücreti nasıl hesaplanır?

Yakıt ücreti ölçümü, birçok blok zincirinin temel kavramıdır; bu, on-chain işlemleri gerçekleştirmek ve depolamak için gereken hesaplama ve depolama kaynaklarının soyut hesaplamasını tanımlar. Yakıt ücreti planı, on-chain tüm yürütmelerin tükettiği maliyetleri belirler ve işlem gerçekleştirme sırasında kullanılan yakıt ücreti harcamasını hesaplamak için kullanılır.

süreç

Etkili bir şekilde uygulamak için, on-chain süreç şudur:

1. tanım ilkeleri;

2. değerlendirme çerçevesi hazırlamak, her bir işlemin fiyatını belirlemek için;

3. için MOVE yakıt ücreti ölçüm sistemi ve güvenli yakıt ücreti cebiri kurmak;

4. yukarı akış yakıt ücreti çerçevesini içe aktar;

5. Yakıt ücreti çerçevesine depolama bilinci kazandırmak;

6. Yakıt ücreti planını daha da ayrıntılandırın.

ilke

Tanımın ilkesi şudur:

1. İşlem maliyeti, ağ üzerindeki kullanılabilir kaynaklara doğrudan bağlı olmalıdır (, örneğin CPU, bellek, ağ, depolama I/O ve alan kullanımı gibi ). Teknoloji ve süreçler geliştikçe, yakıt maliyetleri için gereken maliyetlerin de düşmesi beklenmektedir.

2. Yakıt ücreti on-chain yönetişim tarafından ayarlanmalı ve kesintisiz yapılandırılabilmelidir.

3. Yakıt ücreti, ağdaki sabit kaynak kümesine yönelik DoS saldırılarını önleyebilir ve ağ durumuna göre yönetişim önerileriyle hızlı bir şekilde ayarlanması gerekebilir.

4. Yakıt ücreti fiyatı, hızlanma ve blok zincirinin herkes için erişilebilir olmasını sağlama arzusunu yansıtmaktadır.

5. İyi seçimler yapmayı teşvik edin - örneğin güvenliği, modülerliği, beyanları ve diğer olayları önceliklendirin.

yakıt ücretini hesapla

Kullanıcılar işlem gönderdiklerinde, işlemde iki miktar belirtmek zorundadırlar:

Maksimum Yakıt Ücreti Miktarı: Yakıt ücreti birimi cinsinden ölçülmektedir. Bu, kullanıcının işlemi gerçekleştirmek için harcamak istediği maksimum yakıt ücreti birimi sayısıdır.

Yakıt Ücreti Birimi: Her birim yakıt ücretinin sekizli sistemde hesaplanması, burada 1 sekizli=0.00000001 APT(=$10^{-8}$). Bu, kullanıcının ödemeye istekli olduğu yakıt ücreti fiyatıdır.

İşlem sırasında, işlem için şu ücretler alınacaktır:

1. sabit maliyet, sabit birim artı büyük işlemlerin ek ücretleri.

2. yürütme maliyeti, MOVE talimatını yürütmek için kullanılır.

3. Okuma maliyeti, kalıcı depolamadan veri okumak için kullanılır.

4. yazma maliyeti, verileri kalıcı depolamaya yazmak için kullanılır.

Son işlem ücreti, harcanan yakıt ücreti toplamı ( ile yakıt ücreti birimi çarpılarak ) ile yakıt ücreti birim fiyatı kullanılarak hesaplanabilir. Örneğin, bir işlem 670 yakıt ücreti birimi harcıyorsa ve kullanıcı işlemde belirtilen yakıt ücreti birim fiyatı birim başına 100 Octa ise, son işlem ücreti 670 * 100 = 67000 Octa = 0.00067 APT.

Eğer bir işlem yürütme sürecinde yakıt ücretini tüketirse, gönderici maksimum yakıt ücreti miktarına göre ücretlendirilir ve o işlemin yaptığı tüm değişiklikler geri alınır.

yakıt ücreti planı oluşturma

1. Temel Konfigürasyon

Yakıt ücreti planında, tek bir işlemin detaylarıyla ilgili olmayan birkaç bileşen bulunmaktadır, bunlar arasında işlem boyutu ve maksimum yakıt ücreti birimi (, kullanıcının işlemde belirttiği maksimum yakıt ücreti miktarı ) ile farklıdır.

2. İşlem Ölçeği

Çoğu işlem için, işlem boyutu genellikle binlerce bayt civarındadır. Ancak, MOVE modülünün yayımlanması kolayca birkaç bin bayta ulaşırken, çerçevenin yaklaşık 100 KB olduğu görülmektedir. Çoğu kullanıcı modülünün boyutu genellikle 4KB ile 40KB arasında değişmektedir. Başlangıçta, işlem boyutunun değerini 32KB olarak ayarladık, ancak topluluğun tepkisine göre, uygulama geliştirmeyi basitleştirmek için daha fazla alan talep edildiği için işlem boyutunu 64KB olarak ayarladık.

Son derece büyük ölçekli işlemler, tüm ağın bant genişliği maliyetlerini artırabilir ve performans üzerinde olumsuz etki yaratabilir. Kötüye kullanılırsa, bellek havuzunun daha büyük ölçekli işlemleri göz ardı etmesi teşvik edilecektir; bu nedenle, yaklaşımımız maksimum ölçekli işlemlerin boyutu ve erişilebilirliği arasında bir denge sağlamaktır.

3. En büyük yakıt ücreti birimi

Yakıt ücreti planındaki maksimum yakıt ücreti birimi, bir işlemin en fazla ne kadar işlem gerçekleştirebileceğini tanımlar. Dikkat! Bu, kullanıcının işlemde belirttiği maksimum yakıt ücreti miktarından farklıdır.

Yakıt ücreti planının maksimum yakıt ücreti birimi, bir işlemin ne kadar süreyle gerçekleştirilebileceğini doğrudan etkiler; çok yüksek ayarlanması, blockchain üzerinde olumsuz performans etkilerine yol açabilir. Örneğin, kullanıcı bir while döngüsünde bir artış olduğunu unutabilir ve bu da sonsuz döngüye neden olabilir, bu yaygın bir hatadır. En büyük çerçeve yükseltmelerini gerçekleştirmiş olsak bile, yakıt ücreti planının maksimum yakıt ücreti birimi ('in 1,000,000) olarak ayarlanmış olan %90'ından daha az bir seviyedeyiz.

4. Uygulama

İşlem maliyetlerini değerlendirmek için bir kıyaslama çerçevesi oluşturduk ve bu çerçeveyi yürütürken Move VM'yi analiz etmek için Valgrind kullandık. Çıktısı, her bir kod satırının ne kadar makine komutu ürettiğini bize söyleyen yorumlanmış bir kaynak kodu setidir.

Yukarıdaki analiz yardımıyla, tüm MOVE komutlarının ve yerel fonksiyonların göreli maliyetlerini kabaca tahmin ettik. Ancak, bu yöntemle inline fonksiyonlar arasında bazı sorunlar olduğunu fark ettik: bunlar çağıranın sayımına otomatik olarak dahil edilmez. Ayrıca, bu durumun yalnızca bazı MOVE komutlarını analiz ettiğimizde meydana geldiğini gördük ve bu sorunu sayıları toplamak suretiyle çözebileceğimizi fark ettik.

Daha sonra, sistemin dayanıklılığını ve güvenliğini artırmaya yönelik kodlama örneklerini göz önünde bulundurarak, ekip nihai yürütme makine talimatlarının sayısını belirledi. Bu sayı, yakıt ücreti planındaki mevcut değerlerini belirlemek için depolama ve maksimum yakıt ücreti birimi ile sırasıyla denge sağladı.

5. Depolama

Her seferinde kalıcı depoda saklanan defter durum öğelerine veya verilere erişildiğinde, düğüm depolama cihazına okuma veya yazma talebi gönderir. Her saniyedeki veri erişim toplamı, depolama cihazının bant genişliği ve IOPS kapasitesine bağlıdır. Yakıt ücreti planlaması hesaplama bölümündeki CPU döngülerine benzer şekilde, veri erişimi, blockchain kullanıcılarının sistem yükü altında ücret pazarında rekabet ettikleri anlık kıtlıktır, ayrıca, yazılan verilerin disk alanı maliyeti on-chain'de kalıcıdır. Ekip, bu maliyetleri göz önünde bulundurarak depolama yakıt ücreti planını tasarlamaktadır.

Herhangi bir durum öğesine erişim ve depolama, tüm blok zinciri durumunu doğrulamakla ilgili veri yapısı olan su altı Merkle ağacı ile ilişkili maliyetler yaratır. Bu maliyet, farklı durum öğelerinin kardinalitesi ile ilgilidir ($2^{256}$). Ayrıca, her öğenin boyutu ile orantılı bir maliyet vardır. Bir durum öğesi üzerinde işlem yapmak için, maliyet ( bir sonraki bölümde tanımlanan istisnai durumlar hariç ):

Depolama yakıt ücreti = item_fee + (byte_fee * bytes)

oku, oluştur ve yaz

Durum öğelerine yapılan her erişim aşağıdaki üç türden birine aittir: okuma, oluşturma veya yazma. Erişim, yukarıdaki eşitlikte gösterildiği gibi, öğe ücreti ve bayt ücreti ile ücretlendirilir.

Okuma işlemi en yaygın işlemdir ve yalnızca anlık kaynak kıtlığı ile sınırlıdır. Bu nedenle, okuma ücreti disk IOPS( proje ücreti) ve referans donanım spesifikasyonuna göre bant genişliği kapasitesi ile kalibre edilmiştir.

create, durum deposuna yeni bir öğe eklemektir. Bu nedenle, create kimlik doğrulama veri yapısını artırır, bu da her şeyi daha pahalı hale getirir ve dolayısıyla maliyet en yüksektir. Oluşturma ücreti, ağın sahip olduğu referans disk alanına göre ayarlanır. Bu nedenle, öğe (item_fee) ve bayt (byte_fee) ile diski doldurmak büyük miktarda yakıt ücreti gerektirir.

Yazma işlemleri, durum deposundaki mevcut öğeleri günceller. Bu nedenle, yazma işlemleri kimlik doğrulama veri yapısında ek bir maliyet oluşturmaz. Ancak, mevcut öğeleri daha büyük baytlara değiştirerek diski yine de bozabilirsiniz. Bu nedenle, güncellenen öğelerdeki baytlar için oluşturulduğundakiyle aynı maliyeti alıyoruz.

Dikkat edilmesi gereken husus, depolama ile ilgili maliyetlerin her bir işlem üzerinden değerlendirildiğidir: Aynı kaynağı birden fazla kez okumanız/yazmanız durumunda bile sadece bir kez ücret ödemeniz gerekecektir.

Yukarıdaki hususlara dayanarak, toplam yakıt ücreti bileşenlerini oluşturan 6 yakıt ücreti parametresi tanımladık. Aşağıya bakın:

per_item_read: IOPlara göre düzeltme

per_byte_read: Gerçek bant genişliğine göre kalibre etme

per_item_create: Hedef toplam projeye göre kalibrasyon

per_byte_create: Hedef toplam boyuta göre ayarlama - Her öğenin içerdiği ilk 1KB

per_item_write: per_item_read ile aynıdır

per_byte_write: per_byte_create ile aynıdır

stabil yakıt ücreti birim maliyeti

Herhangi bir işlem ve işlem maliyetinin, depolama ve yürütme maliyetlerine göre sabit bir birim maliyeti gerektirdiği göz önüne alındığında, APT veya yasal para biriminin piyasa değeri ne olursa olsun, sabit yakıt ücreti birim maliyeti, yakıt ücreti planının değişmez kalmasına yardımcı olur ve APT'nin serbest piyasa değerinden ayrıştırılır. Ayrıca, yakıt ücreti biriminin doğru seçimi, yakıt ücreti planının değişmez kalmasına yardımcı olur. Bunu göz önünde bulundurarak, ekip yakıt ücreti birimini yaklaşık 3 basamak hassasiyetle temsil etmektedir. Bu nedenle, para transferi işlem maliyeti yaklaşık 700 yakıt ücreti birimidir.

Topluluk Katılımı

Ne kadar enerji harcarsak harcayalım, yakıt ücreti planımız hala yeterince gelişmiş değil. Bir topluluk projesi olarak, topluluk üyeleri şunları seçebilir:

1. Deneyimlerinize göre, yakıt ücreti planındaki mantıksız yerleri belirleyin;

2. yakıt ücreti planıyla ilgili endişelerinizi dile getirin ve topluluk tartışmalarına katılın.

3. ile yakıt ücretiyle ilgili yönetim teklifine oy verin.

Yakıt ücreti maliyetini nasıl ayarlayabilirim?

Yakıt ücreti planı, on-chain yapılandırma olarak saklanır, ancak yönetişim önerileri aracılığıyla değiştirilebilir ve yeni talimatlar veya yerel işlevler sorunsuz bir şekilde eklenebilir.

Yakıt ücreti planı, yönetim önerileriyle güncellenmesine olanak tanıyan ölçeklenebilirlik için tasarlanmıştır. Move VM'nin sürekli iyileştirilmesi ve kullanıcı geri bildirimlerinin entegrasyonu ile yakıt ücreti parametreleri zamanla ayarlanabilir.

Bazen, yakıt ücreti formülleri, on-chain yapılandırmadan daha karmaşık değişiklikler gerektirebilir. Bu yakıt ücreti formülleri genellikle Rust ile kodlanır ve on-chain yakıt ücreti özellik bayrakları ile ayrılır. Bu formülleri güncellemek için, yeni formüllerle düğüm yazılımını güncellemek ve farklı bir yakıt ücreti özellik bayrağı ile ayırt etmek gerekir. Ardından düğüm yazılımı yayımlanmalı ve düğüm operatörleri tarafından geniş çapta benimsenmelidir; son olarak, yeni yakıt ücreti versiyonunu kullanabilmek için yönetim önerisi yayımlanmalı ve onaylanmalıdır.

Gelecekteki iş

Bu, MOVE için ilk uygulanabilir yakıt ücreti çerçevesidir. Move VM ve Core üzerinde önemli değişiklikler yapılması gerekmektedir. Bu çalışmanın gelecekteki işler için bir zemin oluşturmasını umuyoruz:

1) İşlem maliyetlerini düşürmek, bir gerçek yakıt maliyeti modeline sahip olmak, derleyicinin ve sanal makinenin nerelerde verimli olduğunu gösterir, ekip bunların çoğunu iyileştirerek işlem maliyetlerini düşürebilir.

2) Çok Boyutlu Yakıt Ücreti Hesaplama, kullanıcıların yürütme ve depolama için ayrı bir bütçe belirlemesine olanak tanır. Böylece, kullanıcılar kötü yazılmış uygulamaların uzun yürütme süreleri nedeniyle yüksek yakıt ücreti ödemek zorunda kalmazlar. Ayrıca, blok zinciri tarafındaki işlemler için maksimum yakıt ücreti fiyatının daha detaylı bir şekilde tanımlanmasına da olanak sağlayacaktır;

3) şişkinlik durumunu hafifletme, şu anda durum kümesini küçültmenin basit bir yolu yok, bunun dışında sözleşme ( veya kullanıcı )'ın açıkça nesneleri silmesi. Kullanıcıların verileri silmek için ödeme yapması, arbitraj fırsatları yaratabilir; kullanıcılar ucuzken depolama oluşturup, pahalıyken silerler. Bu zorluğun çözümünü ertelemek, geliştiricilerin on-chain verileri silme motivasyonunu zayıflatabilir. Ekip, her projenin TTL kavramını keşfediyor; bu kavram, TTL süresi dolduğunda erişilmeyen durum öğelerini silecektir.