Artık ağ içindeki bir işlemin yaşam döngüsünü, nihai bir blokta oluşturmaktan kalıcı yürütmeye kadar keşfetmek için tüm öğelere ve sözlüğe sahibiz.
İşlemler, işlem veya akıllı sözleşme kodu yürütme gibi bir işlemi taklit eden bir istemciden harici olarak kaynaklanır. İstemcinin Massa düğümünün IP adresini bilmesi gerekir (bunun nedeni, kendisinin bir düğüm olması ve yalnızca yerel ana bilgisayarı kullanması veya bilinen düğümlerin bazı tutulan listesi ve/veya bazı tarayıcı eklentileri yoluyla olması olabilir) ve ardından işlemi göndermesi gerekir. API modülüne.
Belirli bir düğümde bir işlem kullanılabilir hale geldiğinde, protokol/ağ modülü aracılığıyla diğer tüm düğümlere ve API modülü aracılığıyla fabrikalara yayınlanacak ve böylece ağ havuzunun tüm modüllerinde son bulacaktır.
Diyelim ki harici bir istemciden bir kod yürütme işlemi aldık. İstemcinin blok fabrikasını aynı makinede çalıştıran ve bu düğüme bir işlem gönderen belirli bir düğümü bildiğini varsayalım. Bunlar, aşağıdaki şemada gösterildiği gibi gerçekleşecek olan işlem işlemenin farklı aşamalarıdır:
1- İşlem, API modülü aracılığıyla düğüme girer (işlemin yolu mavi ile işaretlenmiştir).
2- API modülü, işlemi havuz modülüne iletir ve protokol/ağ modülü aracılığıyla diğer düğümlere yayınlar. Bunu duyan diğer düğümler de bunu yayınlayacak (dedikodu protokolü) ve fabrikaları olmayan saf fikir birliği düğümleri olmadıkça havuz modüllerine iletecekler.
3- Bu noktada işlem, çoğunluk düğümü havuzunun bölmelerindedir.
4- Seçici modül, bir sonraki geçerli yuva için blok üretimini kontrol etmek üzere belirli bir düğüm seçer.
5- Seçilen düğümün blok fabrikası, seçim modülünü sorgulayarak (API modülü aracılığıyla) seçimini öğrenir.
6- Bekleyen işlemleri bir havuz modülünde toplayarak bir blok oluşturmaya başlar. Sonuçta, orijinal işlem seçilir ve bloğa entegre edilir. Şimdi bloğu takip edeceğiz (blok yolu yeşil ile işaretlenmiştir)
7- Yeni oluşturulan blok, Graph/Consensus modülüne ulaşmak için API aracılığıyla uzak veya yerel düğümlere gönderilir.
8- Yeni blok, bekleyen DAG bloklarına dahil edilmek üzere ve muhtemelen yeni bir blok kliğine entegrasyon için Grafik/Konsensüs modülü tarafından işlenir.
9- Grafik/Konsensüs modülü, bilgileri ağ genelinde senkronize halde tutmak için Protokol/Ağ modülü aracılığıyla diğer düğümlere yeni bir blok gönderir. Diğer düğümlere ulaşan yeni blok da Grafik/Mutabakat modülüne entegre edilecektir.
10- Genel olarak, bir blok tıklaması yeni bir blokla genişletilir ve böylece yeni bir blok tıklaması bildirimi yoluyla grafik/konsensüs modülünden yürütme modülüne ulaşır. Sonunda, tamamlanırsa son blok olarak da bildirilecektir.
11- Yürütme modülü, güncellenmiş blok kliğinin parçası olan blokları çalıştıracaktır, böylece orijinal blok eninde sonunda yürütülecektir. Bloğun içinde, orijinal olarak gönderilen ve daha sonra olası değişiklikler için deftere uygulanacak olan orijinal işlem bulunur. Bu noktada, değişiklikler kalıcı değildir ve kesinleştirilmiş deftere kıyasla basitçe bir farkta saklanır.
12-Sonunda, blok nihai olarak işaretlenecek ve işlem değişiklikleri de dahil olmak üzere defter değişikliği, kesinleşmiş defterde nihai hale gelecektir.
Orjinal blog yazısı: https://massadopted.com/massa-operation-lifecycle/
