Gerçek cihazlarda blockchain: üç Raspberry Pi ile 72 saat

01Neden gerçek cihazlar

Dağıtık bir sistemde birden fazla düğümün aynı zincirde kalması, tek bir bilgisayardaki süreçlerde kolay görünür. Ağ gecikmesi, sınırlı donanım ve uzun süreli çalışma işin içine girdiğinde tablo değişir. Bu yüzden sistemi yalnızca yerel bir süreçte değil, gerçek cihazlarda ve uzun bir koşuda gözlemlemek istedim.

Tek makinede çalışan birkaç süreç aynı saati, aynı belleği ve aynı ağ yığınını paylaşıyor. Bu, testleri hızlı yapmayı sağlıyor ama bazı soruları görünmez kılıyor. Ayrı cihazlarda çalışan düğümlerin her biri kendi kaynaklarıyla, kendi zamanlamasıyla ve aradaki gerçek ağ üzerinden haberleşiyor. Raspberry Pi gibi sınırlı kaynaklı cihazlar, bu koşulları uzun süre boyunca gözlemlemek için bana uygun bir ortam gibi geldi.

02Mimari

Sistem izinli bir PoA yapısında çalışıyor; kesinleşme imzalı validator oylarıyla sağlanıyor. Blockchain çekirdeği Go ile yazıldı, NestJS katmanı servisleri sunuyor, servisler arasında gRPC ve kalıcı veri için PostgreSQL kullanılıyor. GraphQL ve Docker da yığının parçası. Blok üretimi, validator koordinasyonu, cüzdan ve sözleşme servisleri ayrı sorumluluklar olarak ele alınıyor.

çekirdek    Go (PoA, imzalı validator oyları)
servisler   TypeScript / NestJS
iletişim    gRPC
veri        PostgreSQL
düğümler    3 × Raspberry Pi 4B

Çekirdeği ve servisleri ayrı katmanlarda tutmak bilinçli bir tercih. Konsensüs ve blok üretimi gibi sistemin doğruluğunu belirleyen kısımları, cüzdan ya da sözleşme servisleri gibi dış dünyaya açılan kısımlardan ayırmak, her birini kendi koşullarında değerlendirmeyi kolaylaştırıyor. Bu ayrım dil seçiminde de görünüyor: Go çekirdekte, TypeScript servislerde. Bir katmanda yapılan değişikliğin diğerini nasıl etkilediğini görmek de böylece daha kolay oluyor.

Servislerin TypeScript tarafında olması, çekirdeğin dışındaki işleri daha hızlı denemeyi sağlıyor. Çekirdekte ise öncelik hız değil, öngörülebilirlik. Bir blockchain çekirdeğindeki beklenmedik bir davranış yalnızca bir hata doğurmaz; düğümlerin farklı durumlara sürüklenmesine de yol açabilir.

03İzinli PoA ve kesinleşme

İzinli bir PoA yapısında blok üretme yetkisi, önceden belirlenmiş validator'lara ait. Kesinleşme ise imzalı validator oylarıyla sağlanıyor. Benim için bu modelin öğretici yanı, iki ayrı soruyu birbirinden ayırması: bloklar üretilmeye devam ediyor mu ve üretilen bloklar kesinleşiyor mu? Bir sistem blok üretirken kesinleşme durabilir; tersine, tutarlı görünen bir zincir yeni blok üretmeyi bırakmış olabilir. Bu yüzden uzun bir koşuda ikisine ayrı ayrı bakmak gerekiyor.

İmzalı oylar, kesinleşmenin hangi validator'ların onayıyla gerçekleştiğini de izlenebilir kılıyor. İzinli bir yapı, açık ağlardaki kadar karmaşık bir katılım modeline ihtiyaç duymadan konsensüs ve kesinleşme üzerine çalışmamı sağlıyor. Kişisel bir Ar-Ge projesi için bu, odaklanmak istediğim soruları daraltmanın makul bir yolu.

0472 saatlik test

13–16 Temmuz 2026 tarihleri arasındaki 72 saatlik testte üç Raspberry Pi 4B üzerinde 86.553 blok raporlandı. Düğümler arasında yapılan 863 kontrolde zincir ayrışması ya da kesinleşme durması gözlenmedi.

Bu sayılara bakarken iki şeyi ayırmaya çalışıyorum. Blok sayısı, üretimin koşu boyunca sürdüğünü gösteriyor. Düğümler arası kontroller ise farklı cihazların aynı zinciri paylaşıp paylaşmadığını gösteriyor. Biri olmadan diğeri eksik kalıyor: yüksek bir blok sayısı, düğümler farklı zincirlerde ilerliyorsa bir şey ifade etmez; tutarlı ama duran bir zincir de uzun süreli çalışmayı kanıtlamaz.

Bu tür bir koşuda en değerli bilgi çoğu zaman tek bir sayı değil, sayıların birbirini doğrulaması. Raporlanan blok sayısı ile düğümler arası kontrollerin sonucu aynı hikâyeyi anlatıyorsa koşuya daha çok güvenebiliyorum; ayrışsalardı, asıl incelenmesi gereken o ayrışma olurdu.

Bir düğümün ayakta görünmesi, sistemin çalıştığı anlamına gelmez.

05Bu sonuç neyi söylemiyor

Bu, belirtilen koşuya ait bir bulgu. Sistemin bütün hata senaryolarını kapsamıyor; ağ bölünmesi, kötü niyetli bir validator ya da çok daha fazla düğüm gibi durumlar ayrı testler gerektiriyor. Sonucu bu sınırlarıyla birlikte kaydetmek, sonucun kendisi kadar önemli.

Üç düğüm küçük bir ağ. Daha kalabalık bir validator kümesinde oyların toplanması, ağ gecikmesi ve kaynak kullanımı farklı davranabilir. Bu yüzden 72 saatlik koşuyu bir varış noktası olarak değil, sistemin gerçek cihazlardaki davranışına dair sınırları belli bir gözlem olarak görüyorum.

Uzun süreli çalışmayı doğrulamak; düğümler arası tutarlılığa, blok üretiminin sürmesine ve koşunun sınırlarının kaydedilmesine birlikte bakmak demek. Kişisel bir Ar-Ge projesinde bunu yapmanın bir avantajı var: sonucu daha büyük göstermek için bir baskı yok. Neyi gördüğümü ve neyi görmediğimi aynı açıklıkla yazabiliyorum. Bir sonraki adımları da bu boşluklar belirliyor.