Technical specifications
AUTH ModuleANATHA NETWORK
Sistem Mimarisi
Mimarinin kapsamı, çekirdek blockchain yazılımı, blockchain indexer ve JavaScript SDK’dır, bunlar aracılığıyla istemciyle karşılaşan çeşitli bileşenler çekirdek blockchain’i ve blockchain indexer ile ara yüz oluşturacaktır.
Çekirdek Blockchain
ANATHA Blockchain’e yönelik çekirdek blockchain kısmı, Tendermint Protocol ile güvenli hale getirilecek ve kendi ANATHA SDK’ımızı geliştirmek için Cosmos ekosistemini kaldıraç olarak kullanarak oluşturulacaktır. Tendermint Core, konsensüs motorunun çalıştırılmasını idare etmekte ve P2P bağlantı katmanını yönetmektedir. Bunu yaparken, Tendermint o anda yapılan işlem hakkında hiçbir şey bilmemektedir. İşlem geçerlilik kontrolleri ve işlem yürütme süreci, ANATHA network katmanında modüller olarak adlandırılan ayrı bir fonksiyonelliğe dayalı sonlu durum makinelerinde gerçekleştirilmektedir.
DECENTRALIZED HUMAN READABLE ADDRESS MODÜLÜ
Bu modül, bir ANATHA adresini bir ya da daha fazla insan tarafından okulabilir merkezsiz adrese (DeHRA’lar) ve bunların çoklu para birimi cüzdanları ve diğer kripto adresleri içerebilecek meta verilerine bağlantı sağlayan algoritmaların tamamını içermektedir. Her kullanıcı, birden fazla DeHRA’ya sahip olabilir. Bu DeHRA’ların her biri, native ANATHA Adresine işaret eder. Her bir ANATHA Adresi, kripto para birimine ve aynı kripto para birimi içerisindeki adreslerin sıralamasına göre çoklu para birimlerine ilişkin adreslerin bir haritasını içermektedir.
Kullanıcılar, birden fazla kripto para biriminden birden fazla adres ekleyebilme imkanına sahiptir. ANATHA Platformu içerisindeki bilinen kripto para birimlerinin ilk kaydedilen adresleri için kayıt ücretinde indirim yapılmaktadır. Bundan sonra kaydedilecek her bir adresin kayıt ücreti artacaktır. Ücret mekanizması, networkü aşırı yükleyecek kötü niyetli işlemleri azaltmak amacıyla uygulanmaktadır.
Adresler
ANATHA network, kullanıcıların ikili verileri kullanması gereken her durumda Bech32 adres formatını kullanmaktadır. Bech32 kodlaması, veriler üzerinde güçlü bütünlük kontrolleri sağlamakta ve insan tarafından okunabilir kısmı ise (human readable part (HRP)) bilgilendirici hata mesajları göndererek UI geliştiricilerine yardımcı olabilecek bağlamsal ipuçları vermektedir. ANATHA network’te, anahtarlar ve adresler, network içerisinde hesaplar, validatorler vs. gibi farklı rollerle ilişkili olabilir.
ANATHA NETWORK MODÜLLERİ
Bu bölümde, Ürün dokümanında tanımlanan ANATHA iş mantığını yürütmek için gerekli modülleri anlatacağız. Ayrıca mevcut açık kaynak modülleri yeniden kullanma ve bunları sıfırdan oluşturmaya yönelik çalışmaları paylaşacağız.
Aşağıdaki kısımlardan oluşan Modül Tanım Çerçevesi içerisindeki tüm modülleri sunacağız:
Özet – üst düzey amacı tanımlar
Konseptler – spesifikasyonda geçen özel konseptleri ve tanımları açıklar
Durum- hangi verilerin hangi veri yapıları içerisinde saklandığına dair spesifikasyon
Mesajlar – modül sonlu durum makinesinin işleyebileceği işlemler
Begin Block – herhangi bir begin-block operasyonunu belirtir
End Block – herhangi bir end-block operasyonunu belirtir
Hook’lar – bu modülün çağıracağı/bu modülden çağrılacak mevcut hook’ları açıklar
Keeper’lar – modül fonksiyonları için mantıksal bölünme. Keeper yöntemleri, sadece handler fonksiyonları tarafından başlatılabilir
Event’ler –indeksleme için yayılır. Event’ler, modülden yayılan bir tür ve anahtar ve değeri içermektedir
Parametreler – her bir modül için konfigürasyon noktaları
Bu liste, bağlayıcı değildir ve tüm kısımlar opsiyoneldir.
AUTH Modülü
Özet
Auth modülü, bir aplikasyon için baz işlemi ve hesap türlerini belirmekle sorumludur. Bu modül, tüm temel işlem geçerlilik kontrollerinin (imzalar, tek seferlik anahtarlar, yardımcı alanlar) gerçekleştirildiği ante handler’ı içermekte ve hesap keeper’ı göstermektedir, bu da diğer modüllerin hesapları okumasını, yazmasını ve değiştirmesini sağlamaktadır.
Durum
Hesaplar, bir SDK blockchain’in benzersiz şekilde tanımlanan dış kullanıcısına ilişkin paylaşımlı anahtar (public key), tekrar koruması (replay protection) için adres ve hesap numarası/sıra numarasını içeren kimlik doğrulama bilgilerini içermektedir. Etkinliği sağlamak amacıyla, ücretleri ödemek için hesap bakiyelerinin de çekilmesi gerektiği için, hesap yapıları da bir kullanıcının bakiyesini saklamalıdır.
Mesajlar
Auth modülü, kendisine ait işlem handler’ına sahip olmayacaktır ancak bir işlem üzerinde geçerlilik kontrollerini gerçekleştirmek için kullanılan AnteHandler adında özel bir handler’ı göstermektedir, bu da mempool’dan atılabilmektedir. Ante handler, CheckTx ve aynı zamanda DeliverTx üzerinde çağrılmaktadır.
AnteHandler konfigüre edilebilir ve buna ilave bir kontrol aracı yazılımı eklenebilir. Başlangıçta, AnteHandler aşağıdaki kontrolleri gerçekleştirecektir:
İşlem türü – sadece bilinen işlem türlerine izin verilir
İşlem imza kontrolleri
Ücret meblağ kontrolleri
Keeper’lar
Auth modülü, sadece bir keeper’ı yani AccountKeeper’ı gösterir, bu keeper hesapları okumak ve yazmak için kullanılabilmektedir. Ayrıca tekrar saldırısına karşı koruma için utility fonksiyonlarını da sağlayacaktır. Bu keeper aşağıdaki yöntemleri gösterecektir:
Belirtilen bir adresle bir hesap nesnesi oluşturmak
Ardışık hesap numarası ile bir hesap nesnesi oluşturmak
Store’dan hesap çekmek
Store’a bir hesabı saklamak
Store’dan bir hesabı çıkarmak
Tüm hesaplarda yineleme (iterasyon)
Adresine göre hesapların paylaşımlı anahtarını çekmek
Adresine göre bir hesabın sırasını çekmek
Bir sonraki global hesap numarasını almak
Parametreler
Auth modülü aşağıdaki konfigürasyonları sağlayacaktır:
Bir işleme memo olarak eklenebilecek maksimum veri miktarı. Memo’lar off-chain işlemeyi başlatmak için kullanılabilir
Tek bir işlem içerisine dahil edilebilecek imzaların limiti
İmza verifikasyonlarının boyutu ve maliyetine göre belirlenen işlem ücreti mekanikleri.
İleri Tx Modülü
Özet
Tx modülü, hesaplar arasında coin transferlerini yönetmekten ve belirli hesap türleriyle farklı çalışması gereken özel durum sahte transferlerin (özellikle tasarruf hesaplarının bondingi/unbondingi) takibinden sorumludur. Bu modül, kullanıcı bakiyelerini değiştirmesi gereken diğer modüllerle güvenli etkileşim için farklı kabiliyetleri olan çeşitli ara yüzleri göstermektedir.
Durum
Şu an itibariyle, Tx modülünün kendine ait durumu yoktur — modül sadece auth modülünden AccountKeeper’ı kullanarak hesapları okumakta ve yazmaktadır. Bu uygulama seçiminin amacı, çoğu işlemin coin miktarlarını (ücretler için) içermesini beklediğimiz için gerekli durum okumaları/yazımlarını minimize etmektir, böylelikle hesaplardaki coin verilerinin saklanması soncunda bunların ayrıca okunmasına gerek kalmamaktadır.
Keeper’lar
Tx modülü, hesap bakiyelerini okuması veya güncellemesi gereken diğer modüllere geçirilebilecek üç farklı dışa aktarılmış keeper ara yüzü sağlamaktadır:
BaseKeeper – tam izin erişimi sağlar: herhangi bir hesabın bakiyesini keyfi olarak değiştirebilme ve coin basma veya yakma.
setCoins – bir hesabı adresine göre getirir, hesaba coinleri ayarlar ve hesabı saklar
addCoins/subtractCoins – bir hesabın coinlerini getirir, sağlanan miktarı ekler/çıkarır ve hesabı saklar. Bu da toplam arzı artırır/azaltır
SendKeeper – hesap bakiyelerine erişim sunar ve hesaplar arasında coin transfer edilebilmesini sağlar ancak toplam arzı değiştirmez:
sendCoins – bir hesaptan başka bir hesaba coin transfer eder
ViewKeeper – hesap bakiyelerine sadece salt-okunur erişim sağlar ancak bakiye değiştirme fonksiyonelliği yoktur. Tüm bakiye görüntülemeleri, sürekli olarak ve alan karmaşıklığında gerçekleştirilir:
getCoins – bir hesapla ilişkilendirilen coinleri iade eder
hasCoins – bir hesabın en azından sağlanan coin miktarına sahip olup olmadığına göre iade eder
Mesajlar
Tx modülü, gönderilen birden fazla bakiyenin birden fazla alıcı hesabına transfer edilmesini destekleyen MsgSend işlem türünden yalnızca bir işlemi işlemektedir.
Event’ler
Aşağıdaki event’ler, banka modülünden yayılmaktadır:
Type: transfer, Key: recipient, Value: <address>
Type: transfer, Key: amount, Value: <amount>
Type: message, Key: module, Value: bank
Type: message, Key: action, Value: send
Type: message, Key: sender, Value: <address>
Parametreler
Tx modülü, aşağıdaki konfigürasyonları sağlayacaktır:
Token transfer fonksiyonunun etkileştirilip etkinleştirilmediği. Bu modül, tüm transferlerin kilitleneceği konsensüs protokol test aşaması için kullanılmaktadır.
DAĞITIM Modülü
Özet
Bu Dağıtım modülü, network katılımcıları arasında ödülleri pasif olarak dağıtmanın fonksiyonel bir yolunu uygulamaktadır. Hesaplama optimizasyonu için, bu mekanizma fonları proaktif olarak dağıtmaz, bunun yerine kullanıcılarının ödüllerini işlemesini sağlamaktadır.
Konseptler
Dağıtım modülü, ya modül ya da modül hesapları olabilecek çeşitli havuzlardan oluşmaktadır. Genel dağıtım mekanizması, aşağıdaki diyagramda gösterilmiş olup aşağıdaki unsurlardan oluşmaktadır:
Enflasyon Dağıtımı – Her blokta üretilen %1 yıllık enflasyon Mint modülünden transfer edilir ve Anatha Master Module ve Network Validator Reward Pool’a tahsis edilir
Network Validation Reward Pool Tasarruf Hesabındaki ödüllerin hesaplanmış miktarını kilitler ve kalanı daha önceki blokta kazanılan ödüllerin sonraki bloğunda dağıtır. Tasarruf havuzuna yapılan dışarıya dağıtım, şu şekilde hesaplanır:
Tasarruf Hesapları Modülü, en az 24 saat için kilitli teminata sahip olan tüm tasarruf sahiplerine her 24 saatte bir dağıtımı aktive eder
Anatha Master Modules’ün dağıtım fonksiyonu, günde bir kez tetiklenir ve fonları aşağıdaki şekilde dağıtır:
Dağıtımın %50’si son 24 saat içerisinde HRA sahibi olmuş HRA sahipleri arasında paylaştırılır. Hesap başına bir HRA, ödüle hak kazanır
Dağıtım ücretlerinin %25’i Anatha Kalkınma Fonu Hesabına transfer edilir
Dağıtımın %25’i, Menkul Kıymet Token Sahipleri arasında sahip oldukları menkul kıymet token miktarına göre paylaştırılır
Belirtilen tüm coin dağıtımları proaktif olarak yapılmaz, kullanıcının hesabından çekim yapılmasını başlatan bir işlem göndermeye karar verdiği noktaya kadar saklanır.
Anatha Master Module, blockchain’in işletildiği ilk 365 gün için ödül çekimini bloke eder.
Mesajlar
Dağıtım modülü aşağıdaki mesajları yönetmektedir:
MsgWithdrawValidatorRewardsAll – bir validator ödüllerini çekmek istediğinde, MsgWithdrawValidatorRewardsAll mesajını göndermelidir. Bu işlem, validatorlerin ödüllerini ve riski kendine ait olmak üzere herhangi bir ödül kazancını çeker. Bu işlem mantığının kısımların her biri, unbond gibi bireysel delegasyonlardaki herhangi bir
KRİZ Modülü
Özet
Kriz modülü, blockchain sabitinin ihlal edildiği durumlarda blockchain’i durdurur.
Konseptler
Sabitler, aplikasyon başlatma sürecinde aplikasyonla birlikte kaydedilebilir. Her bir modül, sabitleri rotası dahil olmak üzere kriz modülüne bildirebilir. Sabitler tek tek kontrol edilebilir ve işlem ücretinin ödenmesi gerekmektedir.
Bir sabiti doğrulamak için öngörülen yüksek gas maliyetinden (ve maksimum izin verilebilir blok gas limitini aşma potansiyeli) dolayı, standart gas tüketim yöntemi yerine sabit ücret kullanılmaktadır. Sabit ücretin sabiti standart gas tüketim yöntemi ile çalıştırmanın öngörülüne maliyetinden daha yüksek olması amaçlanmaktadır.
Mesajlar
Blockchain sabitleri, kontrol edilecek sabiti net olarak belirten MsgVerifyInvariant mesajı kullanılarak kontrol edilebilir. Gönderici sabit ücret için yeterli coine sahip değilse ya da sabit rotası kayıtlı değilse bu mesajın başarısız olması beklenmektedir. Bu mesaj, sunulan sabiti kontrol eder ve sabit kırılmışsa panikleyerek blockchain’i durdurur. Sabit kırılmışsa, sabit ücret asla mahsup edilmez çünkü bir blok için işlem asla yapılmış değildir (iadeye eşdeğer). Ancak, sabit kırılmamışsa, sabit ücret iade edilmeyecektir.
Event’ler
Aşağıdaki event’ler kriz modülünden yayılmaktadır:
Type: invariant, Key: route, Value: <route>
Type: message, Key: module, Value: crisis
Type: message, Key: action, Value: verify_invariant
Type: message, Key: sender, Value: <address>
Parametreler
ConstantFeeparam, global param store’da bulunmaktadır.
YÖNETİŞİM Modülü
Özet
Yönetişim modülü, blockchain’in on-chain yönetişim sistemini desteklemesini sağlamaktadır. Merkezsiz yönetim sistemine evrilmeden önce bu modül, eşik on-chain çoklu imza modeli temelinde yönetişim prosedürleri uygulayacaktır, yani sadece genesis blokta kayıtlı olan katılımcılar yönetişim önerilerini oluşturabilecek ve oy kullanabilecektir. Upgrade modülünden faydalanan Yönetişim modülü, merkezsiz yönetişime doğru kendi kendini güncelleyebilecektir (Bu yönetim modülü oluşturulurken, ANATHA Master Contract’dan (ANATHA Ana Sözleşme) yapılacak ilk global dağıtımın ardından fonksiyonel hale gelecektir (soft lansman öncesi 12 ay) ve node operatörleriyle uyumu gerektiren network upgrade aracılığıyla gerçekleştirilecektir. Soft lansmanın 12 ayında, yönetişim iki şeyi yerine getirecektir: Hazine hesabının kontrolünü atayacak ve node yazılım güncellemeleri önerecektir).
Konseptler
Yönetişim süreci, aşağıda açıklanan birkaç adıma ayrılacaktır:
Öneri gönderme: Öneri, daha önceden belirlenen yönetişim yöneticilerinden biri tarafından blockchain’e gönderilir.
Oylama: Öneri önderildikten sonra, oylama açılır. Önceden belirlenmiş diğer yönetişim yöneticileri öneri hakkında oy kullanmak için TxGovVote işlemlerini gönderir.
Öneri yazılım upgrade’i içeriyorsa:
Sinyal: Validatörler, yeni versiyona geçmeye hazır olduklarına dair sinyal vermeye başlar.
Geçiş: Validatörlerin %75’inden fazlası geçiş için hazır oldukları sinyalini verdiğinde, yazılımları otomatik olarak yeni versiyona geçer.
Yönetişim modülünün ilk versiyonunda, iki türden öneri vardır:
PlainTextProposal – Kaynak kodunda modifikasyon içermeyen tüm öneriler, bu türe girmektedir. Örneğin, kamuoyu yoklamasında PlainTextProposal öneri türü kullanılmaktadır.
SoftwareUpgradeProposal – Kabul edildiğinde, validatörlerin yazılımlarını öneriye uygun şekilde güncellemeleri beklenmektedir. Bu mekanizma, Upgrade modülünde açıklanmıştır
Diğer modüllerde gösterilen öneri handler’ları ve türler
Diğer modüller, kendi öneri türleri ve handler’larını uygulayarak yönetişim modülüne göre genişleyebilir. Bu türler, yönetişim modülü kanalıyla kaydedilir ve işlenir (örn. ParamChangeProposal, TreasuryProposal, SofwareUpgradeProposal) ve ardından öneri geçtiğinde ilgili modülün öneri handler’ını yürütür. Bu custom handler, keyfi durum değişikliklerini yapabilir.
İlk opsiyon setinde aşağıdaki seçenekler yer almaktadır: Yes (Evet), No (Hayır), NoWithVeto (Veto ile Hayır), Abstain (Çekimser). NoWithVeto, Hayır olarak sayılır ancak Veto oyu da eklenir. Abstain seçeneği, oy kullananların önerinin lehinde veya aleyhinde oy kullanma niyetleri olmadığı ancak oylamanın sonucunu kabul edecekleri yönünde sinyal vermesini sağlar.
Quorum (Yeter Sayı), oylama sonucunun geçerli olabilmesi için öneri hakkında kullanılması gereken minimum oy hakkı yüzdesi olarak tanımlanmaktadır. Threshold (Eşik), önerinin kabul edilmesi için gerekli olan minimum Evet oyu oranı (Abstain-Çekimser oylar hariç) olarak tanımlanmaktadır.
Başlangıçta, eşik %50 olarak belirlenmiş ancak oyların 1/3’ünden (Çekimser oylar hariç) fazlasının NoWithVeto (Veto ile Hayır) oyları olması halinde veto etme imkanı da getirilmiştir. Yani oylama süresi sonunda Evet oylarının oranı (Çekimser oylar hariç) %50’den fazlaysa ve Veto ile Hayır oylarının oranı 1/3’ten düşükse (Çekimser oylar hariç) öneriler kabul edilir.
Durum
Yönetişim modülünün kullandığı ana veri yapıları şunlardır:
Haritalama haritası[proposalID] -> Öneri. Öneri türü, öneri hakkında İçerik, ID, Durum, Sonuç ve farklı zaman damgaları gibi temel bilgileri saklar
Oylama için Haritalama haritası [proposalID][address]. Bu haritalama, öneri için oy kullanan tüm adresleri ve kullandıkları oyu sorgulamaması sağlamaktadır
Mesajlar
Yönetişim modülünün işlediği mesajlar şunlardır:
TxGovSubmitProposal – öneri gönderme
TxGovVote – oylama işlemi
BASIM Modülü
Özet
Basım mekanizması, sistemde bir enflasyon oranı oluşturmak için tasarlanmıştır. Enflasyon oranı ilk başta yıllık %1 olarak ayarlanmıştır ve günlük olarak (veya blok başına) hesaplanmaktadır. Bu modül, bazı parametrelere göre dinamik bir enflasyon oranın oluşmasını desteklemektedir ancak yıllık %1 sabit enflasyon oranıyla başlamakta ve bu oran yönetişin önerileri veya network upgrade prosedürleri ile değiştirilebilmektedir.
Durum
Basım modülü durumu, iki farklı store’dan oluşmaktadır:
Modül-seviyesinde store – yıllık cari enflasyon oranını ve yıllık beklenen cari karşılıkları tutar. Bu değerler, network tarafından kabul edilen bir önceki blok için her bir blok üzerinde güncellenir
Global parametre store’u – yönetişim önerileriyle değiştirilebilen parametreler. Parametreler bölümünde açıklanmıştır
Begin Block
Basım parametreleri, daha önce işlenmiş olan blok için her bir bloğun başlangıcında yeniden hesaplanmakta ve enflasyon ödenmektedir.
Yıllık hedef enflasyon oranı her bir blok için yeniden hesaplanmaktadır. Enflasyon konfigüre edilirse, istenen staking/tasarruf oranına olan mesafeye bağlı olarak oran değişimine de tabidir (pozitif veya negatif). Yıllık maksimum enflasyon oranı değişimi, maksimum ve minimum yıllık enflasyon değerleri gibi bağımsız olarak ayarlanabilir.
Yıllık karşılıklar, cari toplam arza ve enflasyon oranına göre formül kullanılarak her bir blok üzerinde hesaplanmaktadır:
Blok karşılıkları, yıllık cari karşılıklara göre her bir blok için oluşturulmaktadır. Karşılıklar daha sonra basım modülünün ModuleMinterAccount hesabı tarafından basılmakta ve auth’un FeeCollector modül hesabına transfer edilmektedir. Blok karşılıkları, aşağıdaki formüle göre hesaplanmaktadır:
Parametreler
Basım modülünün global parametre store’unda saklanan konfigüre edilebilir parametreleri:
MintDenom – basılacak coin türü
InflationRateChange – yıllık enflasyon oranı maksimum değişimi
InflationMax - maksimum enflasyon oranı
InflationMin - minimum enflasyon oranı
GoalBonded – bonded varlıkların hedef yüzdesi
BlocksPerYear – yıllık tahmini blok sayısı. Blockchain’de zamana göre hesaplama yapmak için kullanılmamakta ancak sadece tahmini blok karşılıklarını hesaplamak için kullanılmaktadır
Not: Sabit %1 yıllık enflasyon oranı elde edebilmek için, InflationMax ve InflationMin parametrelerinin ikisinin de %1 olarak ayarlanması gerekmektedir.
Event’ler
Kriz modülünden aşağıdaki event’ler yayılmaktadır.
Tür: mint, Key: bonded_ratio, Value: <bonded_ratio>
Tür: mint, Key: inflation, Value: <inflation>
Tür: mint, Key: annual_provisions, Value: <annual_provisions>
Tür: mint, Key: amount, Value: <amount>
PARAMS Modülü
Özet
Params modülü, farklı modülleri konfigüre etmek için kullanılabilecek global olarak mevut bir parametre store’u sağlamaktadır. Bu modül, izin verilen parametre store’u erişimini destekleyebilir.
Konseptler
İki ana türde parametre store’u bulunmaktadır:
Keeper Parameter Store – Tüm mevcut alanlara erişme izni vardır. Bir modül tarafından kullanılabilmesi için, o modülün başlatılması esnasında enjekte edilmesi gerekmektedir.
Subspace – parametre storage’ı için izole ad alanıdır, burada anahtarlar, önceden konfigüre edilmiş alan adları tarafından eklenmiştir. Subspaces, diğer keeper’ların değiştiremeyeceği özel bir parametre store’una ihtiyaç duyan diğer modüller tarafından kullanılabilir.
ÖDÜL/STAKING MODÜLÜ
Özet
Bu modül, blockchain’in Proof-of-Stake sistemini desteklemesini sağlar. Bu sistemde, zincirin native staking token’ına sahip olanlar, validatör olabilir ve nihayetinde sistem için etkili validatörü belirlemek için token’ları stake edebilir. Diğer PoS networkleri arasındaki spesifik fark, bu sistemde tüm validatörlerin stake’lerine eşit aynı oy kullanma hakkına sahip olmasıdır. Bu mekanizma sadece HRA sahiplerine açıktır.
Ödül modülü, kullanıcıların teminatlarını kilitlemesini ve 24 saatlik dönemler halinde bu teminat üzerinden faiz almasını sağlamaktadır. Ödül modülü, fonlarını yatıran hesapların bir listesini saklar. Dev Ojha tarafından önerilen on-chain ücret dağıtım modülünü çalıştırmak içim veri yapılarını saklar. Ödün fonları, Dağıtım modülünde açıklanan Network Validator Reward Pool’dan transfer edilmektedir .
Konseptler
Bir Anatha validatörü, aşağıdaki üç durumdan birinde olabilir:
Unbonded – Validatör, aktif sette değildir. Blokları imzalayamaz ve ödül kazanmazlar.
Bonded – Validatör yeterli miktarda bonded token stake edince, EndBlock esnasında otomatik olarak aktif sete katılırlar ve statüleri Bonded olarak güncellenir. Blokları imzalar ve ödül alırlar. Uygunsuz davranırlarsa shashing yapılır. Bir Validatör Validasyonu durdurmak isterse, bunu duyurmak zorunda kalacaktır ve bir chain-specific param olarak UnbondingTime süresi kadar beklemek. Bu süre içerisinde, token’ların bonded olduğu süre boyunca suç işlerlerse işledikleri bu suçlar için slashing yapılır
Unbonding – Bir validatör kendisi tercih ettiği için veya slashing ya da tombstoning’den dolayı aktif setten çıkarsa, stake’inin unbonding’i başlar ve tokenları BondedPool’dan transfer edilmeden önce belirtilen UnboundingTime süresi kadar devam eder.
Staking’in mevcut uygulamasında, aşağıda belirtilen önemli konseptler bulunmaktadır:
Operatör – bir validatörü çalıştıran ve stake edilen token’ları olan bir antiteyi temsil eden anahtar çifti (keypair)
Validatör – konsensüsa katılan anahtar çifti. Bir operatör, validatör anahtarlarını değiştirmeye karar verebilir. Bunu Tendermint görür.
Validatör seti, validasyon setinde geçirdikleri süre miktarına göre ayrıştırılacak ilk sıralardaki MaxValidators’tan oluşacaktır. Bu set, bekleyen validatörlere teşvik sağlamak için çok sık değiştirilmeyecektir.
Mesajlar
Staking modülü, aşağıdaki mesajları işlemektedir:
MsgCreateValidator – Blockchain’i yeni potansiyel validatör hakkında bilgilendirir, mesaj stake edilecek MinSelfDelegation coinlerin önceden belirlenen miktarını içermelidir
MsgEditValidator – adres, tanım gibi validatör bilgilerinin değiştirilmesini sağlar
MsgBeginUnbonding – Network’ü validatörün konsensüs algoritmasına artık katılmak istemediği hakkında bilgilendirir. Validatörün stake’lerini geri almadan önce UnbondingTime süresi kadar beklemesi gerekmektedir.
End Block
Bir End Block event’inde, çeşitli önemli değişiklikler meydana gelebilir:
Staking validatör seti, bu süreç esnasında güncellenir. Bu sürecin bir parçası olarak, güncellenen validatörler, Tendermint mesajlarını konsensüs katmanında valide etmekten sorumlu Tendermint validatör setine dahil edilmek üzere Tendermint’e geri gönderilir. Yeni validatör seti, haklarına göre ayrıştırılmış ilk sıralardaki MaxValidators’den oluşmaktadır. Validatör seti, öncekiyle karşılaştırılır ve eksik olan tüm validatörler tokenlarını unbonding yapmaya başlar, bu esnada yeni validatörler anında bonded yaoılır. Tüm token transferleri, NotBondedPool ve BondedPool arasında gerçekleştirilir
Bir validatör bonded validatör setinden çıkacağında (jail’e girmesinden dolayı veya yeterli miktarda bonded token’a sahip olmaması nedeniyle), unbonding sürecini başlatır. Bu noktada, validatörün unbonding validatör olmak için olgunlaştığı söylenebilir ve UnbondingTime süresi dolduktn sonra "unbonded validatör" olabilir. Her blokta, validatör kuyruğu olgun unbonding validatörler için kontrol edilecektir. Bu noktada, olgun validatörler durumdan silinir.
Parametreler
Staking modülü, aşağıdaki parametreleri sağlamaktadır:
MinSelfDelegation – tüm validatörlerin vermesi gereken stake miktarıdır, rakamın net olması gerekmektedir
UnbondingTime – validatörlerin validasyonu durdurmaya karar verdikten sonra teminatlarını unlock etmek için gereken süre
MaxValidators – tek bir konsensus roundunda izin verilen maksimum validatör sayısı
BondDenom – Global staking para biriminin nominal değeri
SLASHING Modülü
Özet
Slashing modülü, riskli bir değere sahip olan, protokolün tanıdığı bir aktör tarafından atfedilebilir bir eylemi, cezalandırma yoluyla caydırmaktadır ("slashing"). Cezalar şunları içermektedir:
Stake’lerinin bir miktarını yakma
Belirli bir süre boyunca gelecekteki bloklar üzerinde oy kullanma hakkını kaldırma
Konseptler
Herhangi bir zamanda, sonlu durum makinesinde kayıtlı belirli sayıda validatör bulunmaktadır. Her blokta, jail’e girmeyen ilk sıralardaki MaxValidators validatörleri bonded olur, yani bloklar hakkında öneride bulunabilir ve oy kullanabilir. Bonded olan validatörler risk altındadır, yani protokol hatası yaparlarsa stake’nin bir kısmı veya tamamı risk altındadır.
Slashing modülde yönetilen protokol hataları şunlardır:
Double block işaretleri (Equivocation)
Liveness hataları – Validatörler, belirli sayıda bloklar için pre-commit listesinde yer almamalarından dolayı, otomatik jail, potansiyel slashing yapılarak ve unbonded olarak cezalandırılır
Slashing modülü, tüm slashing suç cezalarının global bir store’unu tutar ancak daha hafif suçlar oldukları için sadece hatalarını yönetir, daha ciddi konsensüs suçları ise Delil modülünde yönetilir.
Liveness slashing, ihlal meydana gelir gelmez derhal tespit edilir ve dolayısıyla daha başka suç delilleri almak için slashing süresine ihtiyaç duyulmaz. Bir validatör derhal jail sürecine alınır ve unjailing işlemi gönderinceye kadar başka bir liveness hatası yapamaz.
Durum
Her bir blok, önceki blok için Tendermint tarafından sağlanan LastCommitInfo olarak bilinen pre-commit seti içermektedir. LastCommitInfo, toplam oy hakkının +2/3’ünden pre-commit içerdiği süre boyunca geçerlidir.
Validatörün liveness aktivitesi hakkında bilgiler, ValidatorSigningInfo üzerinden takip edilebilir. Bu da store’da aşağıdaki şekilde endekslenir:
ValidatorSigningInfo bir haritada saklanır ve anahtar konsensüs adresidir
MissedBlocksBitArray bir haritada saklanır ve anahtar konsensüs adresidir ve değer bir bit array’i temsil eder, her bit bir validatörün bit-array’deki belirli bir endeks için blcok’unun eksik olup olmadığını temsil eder q
ValidatorSigningInfo yapısı aşağıdakilerin kaydını tutar:
Address – Validatörün konsensüs adresi.
StartHeight – Adayın aktif validatör olduğu yükseklik (sıfırdan farklı oy hakkı ile)
IndexOffset – Validatörün bir blokta bonded olduğu ve pre-commit imzalamış veya imzalamamış olabileceği her seferde artırılan endeks
JailedUntil – Validatörün liveness duruş süresi dolana kadar jail edildiği süredir
Tombstoned: Validatörün tombstoned olup olmadığını gösterir. Validatör, sızdırma veya diğer konfigüre edilmiş uygunsuz davranışları sergilediğinde Tombstoned ayarlanır.
MissedBlocksCounter: Gereksiz array okumalarından kaçınmak için tutulan bir sayaçtır. Toplam(MissedBlocksBitArray) her zaman MissedBlocksCounter’a eşittir.
Mesajlar
Slashing modülü, aşağıdaki mesajları yönetmektedir:
Unjail – Bir validatör duruş süresinden dolayı otomatik olarak unbonded olmuşsa ve tekrar online olmak ve muhtemelen bonded sete tekrar katılmak istiyorsa. Validatörün ilk sıralardaki MaximumBondedValidators’da tutulabilecek yeterli stake’i varsa, otomatik olarak rebonded olacaklar ve tekrar ödül toplamaya başlayabilecekler
Begin Block
Her bloğun başlangıcında, her bir validatör için ValidatorSigningInfo’yu güncellemekteyiz ve sliding window’dan liveness eşiğinin altına düşüp düşmediğini kontrol etmekteyiz. Bu sliding window, SignedBlocksWindow tarafından tanımlanmaktadır ve bu penceredeki endeks, validatör’ün ValidatorSigningInfo’sunda yer alan IndexOffset tarafından belirlenmektedir. İşlenen her bir blok için, validatörün imzalayıp imzalamadığına bakılmaksızın IndexOffset artırılır. Endeks belirlendikten sonra, MissedBlocksBitArray ve MissedBlocksCounter buna göre güncellenir.
Son olarak, bir validatörün liveness eşiğinin altına inip inmediğini belirlemek amacıyla, eksik olan maksimum blok sayısını:
ve liveness’ın belirlenebileceği minimum yükseklik olan minHeight’ı getirmekteyiz. Mevcut blok, minHeight’tan büyükse ve validatörün MissedBlocksCounter’ı MaxMissed’ten büyükse, SlashFractionDowntime tarafından slash edilecek, DowntimeJailDuration için jail edilecek ve aşağıdaki değerleri resetlenecektir: MissedBlocksBitArray, MissedBlocksCounter ve IndexOffset.
Parametreler
Slashing modülü aşağıdaki konfigüre edilebilir parametreleri sağlamaktadır:
SignedBlocksWindow
MinSignedPerWindow
DowntimeJailDuration
SlashFractionDoubleSign
SlashFractionDowntime
Not: Açıklama olmayan parametreler Begin Block bölümünde dokümante edilmemiştir.
DELİL Modülü
Özet
Delil modülü, sızdırma ve sahte imza gibi uygunsuz davranışların delillerinin sunulması ve işlenmesini sağlar.
Kavramlar
Bu modül, diğer modüllerin Kriz modülüne benzer şekilde algoritmayı kontrol ederek delillerini kaydetmesi için bir API sağlamaktadır. Sunulan Delil ilk olarak delil modülünün Router’ı aracılığıyla yönlendirilir ve burada o spesifik Delil türü için tekabül eden kayıtlı bir Handler bulmaya çalışır. Her bir Delil türü, başarılı bir şekilde yönlendirilip yürütülebilmesi için delil modülünün keeper’ıyla birlikte kaydedilmiş bir Handler’a sahip olmalıdır. Belirli bir Delil türüne ilişkin Handler, slashing, jailing ve tombstoning gibi keyfi durum geçişlerini gerçekleştirebilir.
Durum
Şu anda, Delil modülü sadece durumda sunulan geçerli Delillerin bir listesini tutmaktadır.
Mesajlar
Delil, MsgSubmitEvidence mesajı ile iletilir. Mesajda sunulan Delil işlenebilmesi ve doğru şekilde yönlendirilebilmesi için Delil modülünün Router’ıyla birlikte kaydedilmiş tekabül eden bir Handler’a sahip olmalıdır.
Begin Block
Aplikasyon düzeyinde işleme yönelik genel çerçevenin dışında, Delil modülü, tespit edilmesi halinde otomatik olarak sunulan altta yatan konsensüs motoru için bir built-in delil handler’ı sunmaktadır. Validatörün uygun şekilde cezalandırılabilmesi için, ilgili bilgiler aplikasyona ABCI Evidence in abci.RequestBeginBlock olarak iletilir.
Şu an itibariyle, delil modülü sadece BeginBlock esnasında Tendermint'sABCIEvidenceTypeDuplicateVote’tan elde edilen Equivocation (double signing) türündeki delilleri işlemektedir.
Geçerli olması halinde, Equivocation delili bir bloka dahil edilir, ihlalin gerçekleştiği zamandaki (delilin tespit edildiği zamandaki değil) validatörlerin stake’i neyse o stake, slashing modülü ile tanımlanan SlashFractionDoubleSign ile slash edilir. Ayrıca, validatör kalıcı olarak jail ve tombstoned edilir, dolayısıyla o validatör bir daha asla validatör setine giremez. Sadece belirtilen MaxEvidenceAge’ten daha eski olmayan Delil dikkate alınacaktır.
Parametreler
Delil modülü, aşağıdaki parametreleri içermektedir:
MaxEvidenceAge – parametreden daha eski olan delil dikkate alınmaz
ARZ Modülü
Özet
Arz modülü, bir zincir içerisindeki coinlerin toplam arzını pasif olarak takip eder, diğer modüllerin coinleri tutabilmesi/coinlerle etkileşim kurabilmesi için bir patern sağlar ve bir zincirin toplam arzını doğrulama için güvenlik sabiti kontrolünü uygular.
Konseptler
Networkün toplam arzı, tüm hesaplardaki tüm coinlerin toplamına eşittir. Toplam arz, bir coinin basıldığı veya yakıldığı her seferde güncellenir.
Arz modülü, modüller tarafından token’ları tahsis etmek ve özel durumlarda tokenları basmak veya yakmak için kullanılabilen yeni bir hesap türü getirmektedir (ModuleAccount). Baz seviyede, bu modül hesapları, hesaplara/hesaplardan ve diğer modül hesapları arasında token gönderebilir/alabilir.
Her bir ModuleAccount’un belirli aksiyonları gerçekleştirmek üzere farklı nesne kabiliyetleri sağlayan farklı izin seti vardır. İzinlerin SupplyKeeper’ın oluşturulması üzerine kaydedilmesi gerekmektedir böylelikle ModuleAccount izin verilen fonksiyonları her çağırdığında, keeper o spesifik hesaba ilişkin izinlere bakabilir ve aksiyonu gerçekleştirebilir veya gerçekleştirmez.
Durum
Arz modülü, sadece zincirin toplam arzının kaydını tutar.
Keeper’lar
Arz keeper’ı, aşağıdakileri yapabilmek içim ModuleAccounts’la bağlantılı olan AuthKeeper ve BankKeeper için wrapper fonksiyonu sağlar:
Adını vererek ModuleAccounts alır ve ayarlar
Diğer ModuleAccounts’lardan veya standart hesaplardan adını aktararak coin alır ve bunlara coin gönderir
ModuleAccounts’tan coin basar veya yakar
UPGRADE Modülü
Özet
Upgrade modülü, canlı bir zincirin yeni (breaking) bir yazılım versiyonuna sorunsuzca upgrade edilmesini kolaylaştırmaktadır. Bunu, blockchain sonlu durum makinesinin önceden tanımlanan bir upgrade blok süresi veya yüksekliğine ulaşılınca ilerlemesini engelleyen bir BeginBlocker hook’u sağlayarak gerçekleştirmektedir. Bu modül, yönetişimin bir upgrade’e nasıl karar verdiğiyle ilgili herhangi bir varsayımda bulunmaz ancak upgrade’in güvenli bir şekilde koordine edilmesi için mekanizma sağlar. Upgrade’ler için yazılım desteği olmadan, canlı bir chain’in upgrade edilmesi risklidir çünkü validatörlerin tamamının sonlu durum makinelerini süreç içerisinde tamamen aynı noktada duraklatması gerekmektedir. Bu doğru bir şekilde yapılmazsa, kurtarması zor olan durum tutarsızlıkları meydana gelebilir.
Konseptler
Upgrade modülü, canlı bir upgrade’in takviminin belirlendiği bir Plan türüdür. Bir Plan, cbelirli bir blok yüksekliğinde ve süresinde ayarlanabilir. Plan, uygun bir upgrade Handler’ıyla birlikte (donmuş) sürüm adayına karar verildiğinde oluşturulmaktadır, burada Plan’ın adı spesifik bir Handler’a tekabül etmektedir. Genel olarak, bir Plan, oylanması ve geçmesi halinde takvimin belirleneceği bir SoftwareUpgradeProposal yönetişim öneri süreci ile belirlenir. Planın Info’su, upgrade hakkında çeşitli meta verileri, tipik olarak validatörlerin otomatik olarak upgrade yapabilecekleri git commit gibi on-chain’e dahil edilecek aplikasyona özel upgrade bilgilerini içerebilir. Upgrade süreci node operatörleri için tamamen otomatik yapılabilir. Info alanına gerekli bilgiler girilerek, ikililer otomatik olarak indirilebilir.
Durum
Upgrade modülünün dahili durumu, nispeten minimal ve basittir. Durum, sadece 0x0 anahtarı ile ve Plan "yapıldı" olarak işaretlenmişse 0x1 anahtarı ile şu anda aktif upgrade Plan’ını (eğer varsa) içermektedir.
Mesajlar
Bu modüle mesajları ileten rotalar, sadece Upgrade planını başlatmanın tek yolu olan Yönetişim modülüne geçirilebilir.
Yönetişim modülünde aşağıdaki mesajlar yer almaktadır:
SoftwareUpgradeProposal
CancelSoftwareUpgradeProposal
TASARRUF Modülü
Özet
Tasarruf modülü, kullanıcıların teminatlarını kilitlemesini ve bu teminatlarından gelen faizi 24 saatlik periyotlar halinde almasını sağlamaktadır.
Durum
Tasarruf modülü, fonlarını yatıran tüm hesapların bir listesini saklar. Bu modül, Dev Ojha tarafından https://drops.dagstuhl.de/opus/volltexte/2019/11400/ üzerinde önerilen on-chain ücret dağıtım modülünü çalıştırmak için veri yapılarını saklayacaktır. Tasarruf fonları Dağıtım modülünde açıklanan Network Validatör Ödül Havuzundan transfer edilecektir.
Mesajlar
Tasarruf modülü aşağıdaki mesajları işleyecektir:
MsgDeposit – kullanıcıların hesaplarındaki mevcut fonların en fazla %25’ini yatırmasını sağlar
MsgWithdraw – kullanıcıların tasarruf hesabından belirtilen miktarda çekim yapmasını sağlar. Bu aksiyon, tasarruf blok süresini resetler ve faiz birikimi ilgili tasarruf hesabına 24 saat veya daha uzun süreyle dokunulmadığı faiz ödeme periyodunda başlayacaktır
MsgWithdrawInterest – kullanıcıların hesaplarına faizi çekmesini sağlar.
Parametreler
Tasarruf modülü, yönetişim tarafından değiştirilebilecek konfigüre edilebilir bir faiz oranı içermektedir.
HRA – AD Modülü
Özet
Bu modül, bir Anatha adresini bir ya da daha fazla insan tarafından okunabilir adreslere (HRA’lar) ve bunların çoklu para birimi cüzdanları ve diğer kripto adresleri içerebilecek meta verilerine bağlayan tüm algoritmaları içermektedir.
Konsept
Her kullanıcı, birden faza HRA’ya sahip olabilir. Bu HRA’ların her biri, native Anatha Adresine işaret eder. Her bir Anatha Adresinde, kripto para birimine ve aynı kripto para birimi içerisindeki adreslerin sıralamasına göre gruplandırılmış çoklu kripto para birimlerinin bir haritası bulunmaktadır. Kullanıcılar, birden fazla kripto para biriminden birden fazla adres ekleyebilmektedir. Bilinen kripto para birimlerinin Anatha Platformu’na ilk kaydedilen adresleri için kayıt ücretinde indirim yapılır. Bundan sonra kaydedilecek her bir adres için kayıt ücreti artırılmaktadır. Ücret mekanizması, networkü aşırı yükleyecek kötü niyetli işlemleri azaltmak amacıyla uygulanmaktadır.
Durum
HRA’ların dahili olarak saklanması için aşağıdaki yapılar tahsis edilecektir:
map[AnathaAddress] -> HRA[] – bir Anatha adresinden adres sahibine ait HRA listesine haritalama.
map[HRA] ->AnathaAddress –HRA’nın hash değerinden adres sahibinin adresine haritalama
map[HRA] ->HraInfo - HRA’nın hash değerinden belirli bir HRA’nın özelliklerinin açıklandığı yapıya haritalama
map[AnathaAddress][CryptocurrencyId][Index] -> Address – bir Anatha adresini çoklu kripto para birimin birden fazla adresine haritalama
Her bir HraInfo yapısı, aşağıdaki alanlardan oluşmaktadır:
ExpiryTime – HRA’nın zaman damgasının sona erme tarihi
Price – HRA’nın uANATHA’da satılabileceği fiyat. Satılık değilse 0’dır
Mesajlar
HRA modülü, aşağıdaki mesajların işlenmesine destek olacaktır:
RegisterHRA – giriş yapanların adresi ile kayıtlı HRA arasında bağ kuracak olan ve parametrelerle ifade edilen maliyeti içeren mesaj. Bu işleme ilişkin ilave veri olarak, kullanıcı Anatha’sıyla bağlantı kurulmasını istediği kripto para cüzdanındaki ilk adreslerini aktarabilir. Bu, HRA’nın ilk kaydıysa, Anatha Cüzdan’da oluşturulan adresler sahipleriyle, adresle otomatik olarak bağlantılandırılacaktır.
RenewHRA – parametrelerle ifade edilen bir ücret karşılığında 1 yıl boyunca bir HRA’nın mülkiyetini uzatacak mesaj
SetSellingPrice – belirli bir HRA’nın fiyatını belirleyen mesaj
BuyHRA – HRA’nın satış fiyatı ile eşleşen arz fiyatı ile birlikte gönderildiğinde HRA’yı alıcıya transfer eden mesaj
DeleteHRA – AnahtaAddress’i kaldıran mesaj -> HRA ilişkisi. Eğer bu kullanıcıların HRA’sının sonuncusuysa, tüm kripto para adres hartaları silinecektir
TransferHRA – HRA’yı başka bir kullanıcıya transfer eden mesaj
RegisterAddress – kullanıcının harici kripto para adresi ile HRA kanalıyla erişilebilecek Anatha Adresi arasında bağ kurmasını sağlar
DeregisterAddress – kullanıcının daha önceden kaydettiği harici kripto para adresini kayıttan çıkarmasını sağlar
Keeper’lar
HRA modülü, adreslerin çevrilmesini gerektiren diğer modüller tarafından erişilebilecek ana keeper’ı gösterecektir. Keeper’ın sağladığı fonksiyonların kabaca listesi şu şekilde olacaktır:
GetHRAInfo - HRA temel bilgilerini geri gönderir
GetHRAByAddress – sağlanan adresin sahibi olduğu tüm HRA’ları geri gönderir
GetAddressByHRA - Anatha adresini geri gönderir
PersistHRAInfo – HRA’yla ilgili değiştirilmiş verileri saklar
Begin Block
Her bloğun budamayı (pruning) da içerecek bakım prosedürlerinin başlangıcında, son tarihi geçmiş HRA bilgileri ve haritalamalar çalıştırılacaktır.
Parametreler
HRADenomination - varsayılan uANATHA
HRAAnnualPrice – önceki parametreyle birlikte, toplam yıllık kayıt fiyatı hesaplanır. Varsayılan 100000000 = 1 ANATHA
HAZİNE Modülü
Özet
Hazine modülü, ilk Anatha arzının saklanmasından, hazine dışına transfer edilen Anatha miktarına göre hazinenin kamu satışı fiyatının oluşturulmasından ve harici Hazine Sisteminin satın aldığı Anatha’yı almaktan sorumludur. Hazine modülü, on-chain çoklu imzalı cüzdan tarafından kontrol edilecektir ve eşik gereklilikleri genesis dosyasında açıklanmıştır. Ürün dokümanındaki hedefleri gerçekleştirmek için, bu on-chain modül, Arka Uç Hizmetleri bölümünde açıklanan tamamlayıcı bir off-chain modülüne gereksinim duymaktadır.
Konseptler
Hazine modülü, rotaları Yönetişim modülüne gösterecektir, bu sayede yine bu modülün yöntemleri başlatılabilecektir.
Hazine modülünde, ANATHA sahiplerinin ANATHA’larını Sipariş olarak gönderebilecekleri ve bunun karşılığında almak istedikleri kripto para birimini belirtebilecekleri bir BuyBack kuyruğu olacaktır. Hazine Backend likiditesi izin verirse, bu modül transferi gerçekleştirecek ve ANATHA’yı alacaktır.
Durum
Hazine modülü, ilk Anatha arzının giren ve çıkan akışlarına göre USD cinsinden sorgulanabilir bir cari fiyat bulunduracaktır. 0.01$’dan başlayan ANATHA token fiyatı, satılan her 10,000,000 (10 million) ANATHA’da 0.01$ artmaktadır.
0 - 10,000,000 token satışı: $0.01
10,000,001 - 20,000,000 token satışı: $0.02
20,000,001 - 30,000,000 token satışı: $0.03
30,000,001 - 40,000,000 token satışı: $0.04
...
7,690,000,001 - 7,700,000,000 token satışı: $7.70
Hazine, çalıştırılacak ve beklemede olan BuyBack Siparişleri kuyruğunu içerecektir:
Kullanıcı başına düşen siparişler [adres] -> Sipariş[]
Global siparişler listesi -> Sipariş[]
Keeper’lar
Hazine modülünün keeper’ı aşağıdaki fonksiyonellikleri sağlayacaktır:
Satış fiyatını güncelleme
Satış fiyatını gösterme
Kuyruktaki Siparişleri yönetme
Mesajlar
TransferFunds – Hazineden belirtilen adrese yapılan yönetişim önerisine dayalı fon transferi
DepositFunds – geri satın alınan Anatha’nın iadesi ve satış fiyatının yenden ayarlanması
SellBack –ilgili ANATHA’yı Hazine fonuna bağlar ve mesaj meta verisi ANATHA sahibinin almak istediği kripto para tanımlayıcısını içerecektir
DeleteOrder – kullanıcının siparişi kaldırmasını sağlar
FulfillOrder – SellBack siparişi tamamlandıktan sonra sadece Hazine arka ucu tarafından gönderilebilecek mesaj. Bu mesaj, kilitli fonları Hazine fonuna doğru serbest bırakacaktır
ANATHA BACKEND HİZMETLERİ/ PANELLER
YÖNETİŞİM Paneli
Yönetişim modülü, blockchain’in on-chain bir yönetişim sistemini desteklemesini sağlar. Merkezsiz yönetişim sistemine evrilmeden önce bu modül, yönetişim prosedürlerini eşik on-chain çoklu imza modeline göre uygulayacaktır, yani sadece genesis blok kayıtlı olan katılımcılar yönetişim önerilerini oluşturup oylayabilecektir. Upgrade modülünün mekanizmasından faydalanan Yönetişim modülü , merkezsiz yönetişime doğru kendi kendini güncelleyebilmektedir.
YÖNETİCİ Paneli
Anatha yöneticilerinin çeşitli özel network verilerine erişmesine ve network aktivitelerini izlemesine imkan tanıyan bir web panelidir. Anatha yöneticileri, aynı zamanda admin panelindeki kontrol panelinden sistem genelindeki belirli ayarları da değiştirebilmektedir.
HAZİNE Paneli
Hazine Arka Ucu, Hazine blockchain modülü ile paralel olarak çalışacak şekilde geliştirilmiştir ve aşağıdakilerden sorumlu olacaktır:
Hazine arka ucunun kontrol ettiği hesaba transfer edilmiş olan ANATHA’ların yönetimi
Çeşitli ödeme yöntemlerinin işlenmesi ve on-chain modül tarafından belirtilen USD satış fiyatına aktarma yapan alıcılara ANATHA’ların geri ödenmesi
İleri düzey bir uygulamada, sistem satın alma siparişini daha ucuza gerçekleştirip gerçekleştiremeyeceğini görmek için piyasa taraması yapacaktır. Bunu yapabilirse, elde edilen karlar Anatha’da kalacaktır
BLOCK Explorer
İşleme ait ve genel networke ait verilere erişim sağlamak için API bağlantısı ve web ara yüzü sağlayan standart bir tarayıcıdır. Explorer network (bloklar, işlemler, adresler, bakiyeler), HRA kaydı (HRA başvurusu, HRA haritaları) ve validatörler (aktif sayı, performans) hakkında genel bilgiler sunmaktadır.
VALIDATÖRLER
Nitelikli bireylerin validatör olarak sisteme girmelerini ve Anatha blockchain bloklarını valide etmelerini sağlayan bir programdır. Validatör güvenliği ve genel parametreler, Anatha networkün öngördüğü standartlara dayalı olarak tanımlanmaktadır. Minimum validatör gereklilikleri arasında, aktif bir HRA’ya sahip olma, stake edilebilecek 500,000 ANATHA’ya sahip olma ve %99 ya da daha fazla sunucu çalışma sürense (server up-time) sahip olma yer almaktadır.
Limitler:
Başlangıçtaki maksimum node sayısı - 50
Sondaki maksimum node sayısı - 300
Bekleme listesindeki maksimum node sayısı - sınırsız
Anatha’nın çalıştırdığı toplam node sayısı - 3
Bekleme listesi için lider tahtası (Leaderboard)
INDEXER
Endeksleme hizmeti, işlemleri cüzdan adreslerine göre ve işlem hash’lerine göre endekslemektedir, bu da belirli bir adresle ilişkili işlemlerin filtrelenmesini daha kolay hale getirmekte ve tek bir işlemi benzersiz hash değerine göre (tüm işlem nesnesinin SHA256 hash değeri) sorgulanmasını kolaylaştırmaktadır.
Endeksleme hizmeti, mevcut blockchain node’larından gelen yeni işlemlere sürekli olarak abone olmakta ve endekslenmiş verileri Redis datastore’da saklamaktadır. Hangi sebeple olursa olsun endeksleme hizmeti çalışmayı durdurursa, mevcut verileri kaybetmeyecektir ve senkronizasyon sürecini en son kaydedilen bloktan itibaren devam ettirecektir. Endeksleme sürecinin bir parçası olarak, geçersiz işlemler de kaydedilecektir ancak geçersiz bayrağı ile işaretlenecektir.
Endeksleme hizmeti, doğrudan blockchain’den sorgulanamayan bilgileri sunan yüksek erişimli bir API sunmaktadır. Bu API’ler, blockchain tarayıcısı, cüzdan vs. gibi çeşitli ön yüzler tarafından kullanılacaktır.
Indexer’ın endeksleyeceği bazı unsurları listelemek gerekirse:
Sona erme tarihine göre HRA
Adrese göre işlemler
ANATHA JavaScript SDK
Nmp kaydından kurulabilecek Anatha SDK is a JavaScript/Node.js kütüphanesidir. Bu kütüphane, Anatha blockchain ile iletişim kurma yöntemlerini içermektedir. Anatha SDK’nın geliştiriciler tarafından Anatha blockchain ile etkileşim kurmak ve bunun üzerinde ara yüzler ve aplikasyonlar kurmak üzere kullanılması amaçlanmaktadır.
Anatha SDK, tüm işlem türlerini içe aktaracak ve yararlı yüklerin oluşturulması ve Core’da belirtilen her bir işlemin imzalanması için bir ara yüz sağlayacaktır. İşlemlerin hazırlama, imzalama ve aktarma dışında, Anatha SDK blockchain sorgulama kabiliyetlerine de sahip olacaktır. Ayrıca, cüzdanla bağlantılı ilgili fonksiyonellikleri de destekleyecektir. Bu bağlamda, SDK, CLI’nın 19 fonksiyonelliğinin aynılarını sağlayacaktır ancak bunları JavaScript ortamına uygun hale getirecektir. SDK’nın şu anda sunduğu fonksiyonelliklerin bazıları şunlardır:
Anatha cüzdanı başlatma (anahtar çifti)
Anahtar çiftini üreterek
Ham özel anahtarı içe aktararak
Bir adresin bakiyesini kontrol etme
Anatha coinlerini imzalama ve üzerinde işlem yapma
Her blokta ve her işlemde meydana gelen WebSocket event dinleyicileri
Module Query ve İşlemle bağlantılı fonksiyonellik:
Bağlı node’un sorgu durumu
Sorgulama:
Blok – belirli bir yükseklikteki bir bloğun doğrulanmış verilerini alma
İşlemler – belirli etiketlerle (Event’ler) veya hash değeri ile eşleşen tüm işlemleri arama
Hesap bakiyesi
Her modülde gösterilen durum (Yönetişim, Dağıtım, Staking, Slashing, HRA, Tasarruf, Hazine, ...)
İşlem Yapma:
İmzalanmış bir işlem oluşturma ve aktarma
Offline oluşturulan imzaları yayınlama
Her modülde gösterilen mesajlar (Yönetişim, Dağıtım, Staking, Slashing, HRA, Tasarruf, Hazine, ...)
Komut Satırı Araçları
Bir aplikasyonun temel ara yüzlerinden biri, komut satırı ara yüzüdür. Bu giriş noktası, son kullanıcıların mesaj oluşturabilmesi ve sorgu yapabilmesi için aplikasyonun modüllerinden komutları ekler.
İşlemler, kullanıcılar tarafından geçerli bir bloğa dahil edildiklerinde durum değişikliklerini tetikleyen mesajların paketlemesi ile oluşturulmaktadır. İşlem komutları tipik olarak her modülde tx.go dosyası olarak gösterilmektedir.
Sorgular, kullanıcıların aplikasyon veya network durumu hakkında bilgi toplamasını sağlamaktadır; aplikasyon tarafından yönlendirilmektedir ve tanımlandıkları modül tarafından işlenmektedir. Sorgu komutları tipik olarak kendilerine ait query.go dosyasına sahiptir.
CLI Aracı, anathacli olarak adlandırılacak ve çalıştırılabilir bir derlenmiş Golang ikilisi olacaktır.
Listelenen modüllerden gelen her Mesaj, CLI tarafından işlenebilir.
Last updated
