``

Temel fikir: Paylaşılan bir durum makinesi

Akıllı sözleşme, blok zincire yerleştirilmiş programdır. Ethereum gibi ağlarda kod, Ethereum Sanal Makinesi üzerinde yürütülür. Sözleşmenin bakiyesi, yetkili adresleri ve ödeme durumu kalıcı veriler olarak saklanır.

Bunu bir durum makinesi gibi düşünebiliriz: Sözleşme başlangıçta ödeme bekliyor, ardından fonlandı, son olarak ödendi durumuna geçer. Her geçişin koşulları vardır. Yetkisiz bir kullanıcı düğmeye bassa bile programın kontrollerini geçemez. Güven, tarafların iyi niyetinden çok, kodun doğruluğuna ve ağın güvenlik varsayımlarına dayanır.

“Otomatik” ödeme hangi adımlarla gerçekleşir?

1. İşlem oluşturulur: Kullanıcı, sözleşmenin bir fonksiyonunu çağıran işlemi özel anahtarıyla imzalar.
2. Kod yürütülür: İşlemi işleyen düğümler, ilgili blok bağlamında aynı kuralları uygulayarak sonucu hesaplar.
3. Durum güncellenir: Koşullar sağlanırsa bakiye ve kayıtlar değişir. Bir kontrol başarısız olursa işlem geri alınır; harcanan işlem ücretleri genellikle yine ödenir.

Buradaki kritik ayrıntı şudur: Sözleşmeler kendiliğinden uyanıp çalışmaz. Bir işlemle tetiklenmeleri gerekir. Zamanlanmış işler için harici otomasyon hizmetleri kullanılabilir; bunlar da sonuçta zincire işlem gönderir.

Ödeme kuralını şöyle özetleyebiliriz:

Burada $B$ emanetteki tutar, $A$ yetkili alıcının onayı, $K$ ise sözleşmenin kapanmış olmasıdır. Gösterge fonksiyonu, koşul doğruysa bir, yanlışsa sıfır üretir. Yani onay yoksa veya ödeme zaten yapıldıysa transfer gerçekleşmez.

Solidity ile küçük bir emanet kasası

Aşağıdaki örnek, alıcının sözleşmeyi oluştururken yatırdığı ETH’yi saklar. Yalnızca aynı alıcı onay verdiğinde satıcıya ödeme yapar.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Emanet {
    address public immutable alici;
    address payable public immutable satici;
    uint256 public immutable tutar;
    bool public kapandi;

    constructor(address payable _satici) payable {
        require(msg.value > 0, "Bos emanet");
        require(_satici != address(0), "Gecersiz satici");
        alici = msg.sender;
        satici = _satici;
        tutar = msg.value;
    }

    function teslimatiOnayla() external {
        require(msg.sender == alici, "Yetkisiz kullanici");
        require(!kapandi, "Zaten odendi");

        kapandi = true;
        (bool basarili, ) = satici.call{value: tutar}("");
        require(basarili, "Transfer basarisiz");
    }
}

payable, oluşturma sırasında ETH kabul edilmesini sağlar. msg.sender çağıranın adresidir; msg.value gönderilen tutarı belirtir. immutable alanlar oluşturulduktan sonra değiştirilemez. require ifadeleri ise geçersiz işlemleri durdurur.

Önemli güvenlik ayrıntısı, kapandi değişkeninin dış adrese para gönderilmeden önce güncellenmesidir. Bu, kontroller–etkiler–etkileşimler düzenidir: Önce koşulları denetle, sonra iç durumu değiştir, en son dış çağrı yap. Transfer başarısızsa require tüm bu durum değişikliklerini geri alır.

Blok zincir kargonun geldiğini nereden bilir?

Bilmez! Örnekte “teslimat”, alıcının onayı anlamına gelir; fiziksel teslimatın bağımsız kanıtı değildir. Kargo şirketinden bilgi alınacaksa oracle gerekir. Oracle, dış veriyi zincire taşıyan bir mekanizmadır ve sisteme yeni güven varsayımları ekler.

Bu yüzden “kod aracıları tamamen kaldırır” sözü her senaryoda doğru değildir. Özellikle fiyat, hava durumu veya teslimat gibi verilerde kaynağın doğruluğu, güncelliği ve manipülasyona dayanıklılığı ayrıca değerlendirilmelidir.

Gerçek kullanımda eksik parçalar

Bu örnekte alıcı hiç onay vermezse para kilitli kalır. Üretim tasarımında süreli iade, anlaşmazlık çözümü, olay kayıtları ve kapsamlı testler düşünülmelidir. Yeniden giriş saldırıları, erişim yetkileri ve yükseltme mekanizmaları ayrıca incelenmelidir.

İşlem ücretleri küçük ödemeleri pahalılaştırabilir; blokta görünmek de her ağda aynı kesinlik düzeyini sağlamaz. Akıllı sözleşme sihirli noter değildir: Açıkça tanımlanmış koşulları uygular. Başarılı tasarımın sırrı, yalnızca mutlu ödeme yolunu değil, herkesin fikrini değiştirdiği ve sistemlerin aksadığı günleri de kodlamaktır.

``

Güvenliğin üç temel direği

Finansal güvenlik üç hedef üzerinde yükselir: gizlilik, veriyi yetkisiz kişilerin okuyamaması; bütünlük, işlem bilgilerinin izinsiz değiştirilememesi; erişilebilirlik, hizmetin ihtiyaç anında çalışmasıdır. Şifreleme ilk iki hedefe katkı sağlar; ancak tek başına hizmet kesintilerini veya yanlış yetkilendirmeyi çözmez.

Örneğin, saldırgan şifreli bir havalenin tutarını değiştirememeli, aynı talimatı tekrar göndererek ikinci ödeme oluşturamamalıdır. Bunun için şifrelemeye ek olarak kimlik doğrulama, işlem yetkilendirmesi ve tekrar saldırılarını önleyen kontroller gerekir. Sağlam bir kasa, yanlış kişiye verilen anahtarı telafi edemez!

“Uçtan uca” gerçekten ne demek?

Bu ifade dikkatli kullanılmalıdır. Mobil uygulama ile banka ağ geçidi arasındaki TLS bağlantısı, aktarım sırasında koruma sağlar. TLS ağ geçidinde sonlanıyorsa veri orada çözülebilir; dolayısıyla bütün işlem zinciri otomatik olarak gerçek uçtan uca şifrelenmiş sayılmaz.

Gerçek uçtan uca şifrelemede içerik yalnızca belirlenen uçlarda okunabilir. Bankanın işlemi gerçekleştiren uygulamasının veriyi görmesi gerektiğinden, finansal mimariler çoğunlukla farklı güven sınırlarında birbirini tamamlayan korumalar kullanır.

TLS 1.3 güçlü bir güncel tercihtir; doğru yapılandırılmış TLS 1.2 de bazı uyumluluk senaryolarında kullanılabilir. Sertifika doğrulamasını kapatmak ise güvenlik kapısını dekoratif hale getirir.

Standartlar: Aynı işi yapmayan kurallar

PCI DSS, kapsam dahilindeki ödeme kartı verilerinin korunmasına yöneliktir; bütün bankacılık verileri için evrensel bir şifreleme standardı değildir. ISO/IEC 27001, bilgi güvenliği yönetim sistemini ele alır. KVKK ve ilgili bankacılık düzenlemeleri ise veri işleme ve güvenlik yükümlülükleri getirir.

Kriptografik modüller için FIPS 140-3, anahtarların yaşam döngüsü için NIST SP 800-57 önemli referanslardır. Bunların zorunluluğu kurumun faaliyet alanına ve mevzuata bağlıdır. Sertifika sahibi olmak, uygulamadaki bütün açıkların kapandığı anlamına gelmez; denetim ve güvenli geliştirme devam etmelidir.

Şifreleme ile bütünlüğü birlikte korumak

AES-GCM gibi doğrulanmış şifreleme yöntemleri, içeriği gizlerken değiştirilmesini de saptar. Mantığını şöyle özetleyebiliriz:

Burada $P$ açık veri, $K$ anahtar, $N$ nonce, $A$ ek doğrulanan veri, $C$ şifreli içerik ve $T$ doğrulama etiketidir. Ek veri gizlenmez; fakat değiştirilirse doğrulama başarısız olur. Aynı anahtarla nonce tekrar kullanılmamalıdır.

Aşağıdaki Python örneği, işlem içeriğini şifreler ve işlem kimliğini içerikle ilişkilendirir:

import json
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

key = AESGCM.generate_key(bit_length=256)
aead = AESGCM(key)
nonce = os.urandom(12)
aad = b"transaction:tx-1042"
payload = json.dumps({
    "amount_kurus": 12500,
    "currency": "TRY"
}).encode("utf-8")

ciphertext = aead.encrypt(nonce, payload, aad)
plaintext = aead.decrypt(nonce, ciphertext, aad)
print(json.loads(plaintext))

Parasal tutarı kayan noktalı sayı yerine kuruş cinsinden tam sayı olarak tutuyoruz. decrypt, içerik veya ek veri değişmişse doğrulama hatası verir. Bu, öğretici bir örnektir: üretimde anahtar yönetimi HSM veya KMS ile tasarlanmalı; nonce benzersizliği, anahtar yenileme ve kalıcı kayıt stratejileri ayrıca uygulanmalıdır. Anahtarı şifreli verinin yanına açık biçimde koymak korumayı boşa çıkarır.

Şifrelemenin dışındaki kritik savunmalar

HSM, anahtarların korunmasına ve kriptografik işlemlerin kontrollü yürütülmesine yardımcı olur. Bunun yanında en az ayrıcalık, görev ayrılığı, çok faktörlü doğrulama ve hassas işlem onayı gerekir.

Tekrar saldırıları için benzersiz işlem kimlikleri ve atomik idempotency kontrolleri kullanılmalıdır: aynı talimat ikinci kez ödeme üretmemelidir. Loglar denetlenebilir olmalı, ancak kart bilgilerini veya sırları açıkça taşımamalıdır. Yedeklerin geri yüklenmesi ve anahtar kurtarma süreçleri de düzenli test edilmelidir.

Sonuçta güvenli bankacılık, tek bir algoritmanın zaferi değildir. Doğru kriptografi, sınırlı yetkiler, güvenli uç cihazlar ve sürekli izleme birlikte çalışır. Dijital kasanın gücü, en parlak kilidinden değil, en zayıf bağlantısının sağlamlığından gelir.

``

Dayanıklılık, Sadece Fazladan Sunucu Değildir

Yedeklilik, aynı görevi yapabilecek alternatif kaynakların bulunmasıdır. Dayanıklılık ise arızayı algılama, etkisini sınırlama, alternatif kaynağa geçme ve toparlanma yeteneğidir. Garajda yedek lastik bulunması güzeldir; fakat lastiği değiştiremiyorsanız yolculuk yine durur!

Kullanılabilirlik, basitleştirilmiş bir modelde şöyle ifade edilir:

Burada MTBF arızalar arasındaki ortalama çalışma süresi, MTTR ise ortalama hizmeti geri getirme süresidir. Dolayısıyla yalnızca arızaları azaltmak değil, toparlanmayı hızlandırmak da kullanılabilirliği yükseltir.

Bağımsız iki bileşenden herhangi birinin hizmet vermesi yeterliyse, kusursuz geçiş varsayımı altında:

Her bileşen yüzde 99,9 kullanılabilir olduğunda teorik sonuç yüzde 99,9999 olur. Ancak ortak elektrik, ağ veya yazılım hataları bu hesabın bağımsızlık varsayımını bozar.

Yedekliliğin Farklı Lezzetleri

İki sunucuyu aynı fiziksel makinede çalıştırmak, iki şemsiyeyi aynı delik çantaya koymaya benzer. Gerçek yedeklilik, arıza alanlarını ayırır: farklı makineler, erişilebilirlik alanları veya bölgeler. Yük dengeleyici, DNS, kimlik servisi ve bağlantı altyapısı da tek hata noktası bakımından incelenmelidir.

Aktif-pasif tasarımda yedeğin güncel veriye erişmesi gerekir. Aktif-aktif yaklaşımda ise eşzamanlı güncellemeler, veri çatışmaları ve oturum yönetimi özellikle önem kazanır.

İki Lider, Bir Büyük Sorun

Ağ bölünmesi sırasında iki düğüm kendisini lider sanabilir. Split-brain denen bu durum, aynı siparişin farklı biçimlerde işlenmesine neden olabilir. Çözüm yalnızca daha fazla kopya değildir; lider seçimi ve yazma yetkisinin sınırlandırılması gerekir.

Çoğunluk gerektiren bir karar için:

Üç oy veren düğümde çoğunluk ikidir. Bu yapı, uygun bir konsensüs protokolüyle bir düğüm kaybına dayanabilir. Eski liderin yazmasını engellemek için hedef kaynağın doğruladığı fencing token kullanılabilir. Ağ bölünmesinde tutarlılığı korumak bazen bazı isteklere hizmet verememeyi gerektirir.

Kurtarma Hedeflerini Sayıya Dökün

• RTO: Hizmeti geri getirmek için hedeflenen azami süre.
• RPO: Kabul edilebilir veri kaybının zaman karşılığı.

Örneğin RTO iki dakika, RPO otuz saniye olabilir. Asenkron replikasyon veri kaybı riski taşırken senkron replikasyon gecikmeyi artırabilir. Yedekleme ise ayrı bir ihtiyaçtır: Replikasyon, yanlışlıkla silinen veriyi de kopyalayabilir. Bu yüzden geri yükleme testleri şarttır.

Yeniden Deneyin, Ama Sonsuza Kadar Değil

Geçici bağlantı sorunlarında sınırlı tekrar yararlıdır. Aşağıdaki Python 3.11+ örneği, asenkron bir okuma işlemini toplam süre bütçesi içinde yeniden dener:

import asyncio
import random

async def resilient_read(fetch):
    async with asyncio.timeout(2.0):
        for attempt in range(3):
            try:
                return await asyncio.wait_for(
                    fetch(), timeout=0.5
                )
            except (TimeoutError, ConnectionError):
                if attempt == 2:
                    raise
                delay = random.uniform(
                    0, 0.1 * 2 ** attempt
                )
                await asyncio.sleep(delay)

fetch, gerçek ağ çağrısını yapan asenkron fonksiyondur. Her denemenin zaman aşımı vardır; toplam bütçe iki saniyedir. Rastgele bekleme, yani jitter, istemcilerin aynı anda tekrar saldırmasını azaltır. Yazma işlemlerinde tekrar kullanacaksanız idempotency anahtarıyla yinelenen işlemleri önlemelisiniz.

Sürekli başarısız olan bağımlılıklarda circuit breaker, yeni çağrıları geçici olarak keser. Bulkhead yaklaşımı ise bağlantı ve işçi havuzlarını ayırarak bir servisin kaynakları tüketip diğerlerini sürüklemesini önler.

Dayanıklılığı Test Etmeden İnanmayın

Gecikme, hata oranı, replikasyon gecikmesi ve geçiş süresi izlenmelidir. Önce izole ortamda düğüm kaybı ve ağ kesintisi deneyleri yapın; üretim deneylerini dar kapsam ve durdurma koşullarıyla yürütün. Kapasiteyi de sınayın: Yedek sistem bütün trafiği taşıyamıyorsa yalnızca dekoratif bir yedektir.

Son olarak, kritik işlevleri önceliklendirin. Öneri servisi kapanabilir; ödeme doğruluğu kapanamaz. Doğru sonuç üretilemiyorsa güvenli biçimde durmak, hatalı işleme devam etmekten iyidir. Dayanıklılık, daha çok sunucu değil, arıza anında daha doğru karar demektir.

``

Navigasyonun üç katmanı

Otonom navigasyonu üç çalışanı olan küçük bir köprüüstü gibi düşünün: durum kestirici nerede olduğunuzu söyler, rota planlayıcı güvenli yolu seçer, kontrolcü ise dümen ve itkiyi yönetir. Bu görevleri ayırmak, hem yazılımı test etmeyi hem de arızaların kaynağını bulmayı kolaylaştırır.

GNSS konumu ve yer üzerindeki hızı sağlar. IMU ivme ve açısal hareketleri ölçer; pusula baş açısına yardımcı olur. Ancak hiçbiri kusursuz değildir. GNSS kesilebilir, pusula manyetik etkilerden sapabilir, IMU hataları zamanla birikebilir. Genişletilmiş Kalman filtresi gibi yöntemler, hareket modeliyle ölçümleri birleştirerek daha tutarlı bir durum tahmini üretir. Zaman damgalarının uyumu da en az sensör seçimi kadar önemlidir.

Baş açısı ile rota açısı aynı değildir

Aracın burnunun baktığı yön, baş açısı $ψ$; yer üzerindeki hareket yönü ise rota açısı $χ$ olsun. Akıntı varsa bu iki açı farklı olabilir. Burnunu kuzeye çevirmiş bir araç, doğuya akan su nedeniyle kuzeydoğuya ilerleyebilir.

Basitleştirilmiş yatay düzlem modeli şöyledir:

Burada $\mathbf{v}b$ suya göre hızı, $\mathbf{v}_c$ akıntıyı, $R(ψ)$ gövde koordinatlarından dünya koordinatlarına dönüşümü temsil eder. Yer hızından $χ=\operatorname{atan2}(v{g,y},v_{g,x})$ hesaplanır. Dolayısıyla yalnızca baş açısını sabitlemek, çizilen rotayı korumaya yetmez.

Rotayı kovalamak yerine önüne bakmak

Yaygın çözümlerden biri, görüş hattı anlamına gelen LOS yönlendirmesidir. Sistem, rota üzerinde ileride bulunan hayali bir noktaya yönelir. Böylece küçük sapmalarda sert dönüşler yerine yumuşak yaklaşmalar üretir.

Düz bir rota parçasında yanal hata $e$, rota yönü $γ$ ve ileri bakış mesafesi $Δ$ için:

Buradaki $β$, süzülmüş $χ-ψ$ farkıyla yaklaşık olarak kestirilebilen sürüklenme açısıdır. Küçük $Δ$ daha çevik fakat daha salınımlı davranış yaratabilir. Büyük $Δ$ ise dönüşleri yumuşatırken rotaya dönüşü yavaşlatır. Çok düşük hızlarda rota açısı güvenilir olmadığından sürüklenme kestirimi sınırlandırılmalıdır.

Python ile yönlendirme ve dümen kontrolü

Aşağıdaki örnek, LOS hedefini hesaplar ve baş açısı hatasını PI kontrolcüyle dümen komutuna dönüştürür. Koordinatlar metre cinsinden yerel düzlemde, açılar radyan cinsindedir. İntegral terimi kalıcı sapmayı azaltırken koşullu güncelleme, dümen doygunluğunda gereksiz birikimi önler.

import math


def wrap(angle):
    return (angle + math.pi) % (2 * math.pi) - math.pi


def los_heading(position, start, end, beta, lookahead=15.0):
    dx, dy = end[0] - start[0], end[1] - start[1]
    length = math.hypot(dx, dy)
    if length == 0 or lookahead <= 0:
        raise ValueError("Geçersiz rota veya bakış mesafesi")
    px, py = position[0] - start[0], position[1] - start[1]
    error = (dx * py - dy * px) / length
    course = math.atan2(dy, dx) - math.atan2(error, lookahead)
    return wrap(course - beta)


def steering(target, heading, integral, dt):
    if dt <= 0:
        raise ValueError("dt pozitif olmalı")
    error = wrap(target - heading)
    raw = 1.2 * error + 0.04 * integral
    command = max(-0.6, min(0.6, raw))
    if abs(raw) < 0.6 or raw * error < 0:
        integral += error * dt
    return command, integral

wrap, açı sınırında yanlışlıkla tam tur dönülmesini engeller. İntegral değeri kontrol döngüleri arasında korunmalıdır. Katsayılar yalnızca örnektir; gerçek araçta hız, gövde dinamiği ve dümen sınırlarına göre ayarlanır. Ayrıca dümen işaretinin modelle uyumu doğrulanmalıdır. Bu kod, waypoint geçişlerini veya engelden kaçınmayı kapsamaz.

Her dalgayla kavga etmeyin

Dalga kaynaklı hızlı salınımları sürekli dümenle düzeltmek enerji tüketir ve mekanizmayı yorar. Uygun filtreleme ve kontrol bant genişliği, yavaş rota sapmalarını hızlı yalpalamadan ayırmaya yardımcı olur. Ancak aşırı filtreleme gecikme yaratır; bu yüzden kontrolcü, sensör ve gövde birlikte değerlendirilmelidir.

İtki kontrolü de önemlidir: birçok dümenli araç düşük hızda yönlendirme otoritesini kaybeder. Akıntı aracın kapasitesini aşıyorsa hiçbir yazılım istenen rotayı garanti edemez. Sistem güvenli bekleme, alternatif rota veya operatöre devretme davranışına geçmelidir. Trafikte ise çarpışma riski ve uygulanabilir COLREG kuralları ayrıca ele alınmalıdır.

Başarılı otonomi, denizi yenmek değil, etkilerini ölçüp yönetmektir. Önce simülasyonda akıntı, sensör kesintisi ve aktüatör sınırlarını deneyin; ardından kontrollü deniz testlerinde yanal hata, enerji tüketimi ve güvenlik davranışlarını karşılaştırın.

Bir enerji santralinde yanlış bakım zamanı, hem üretimi hem bütçeyi yakabilir. Peki türbini durdurmadan önce kararınızı sanal bir santralde deneseydiniz? Dijital ikiz, gerçek tesisten gelen verilerle güncellenen bir modeldir: Operatörlerin pahalı sürprizler yaşamadan “Ya şöyle yapsak?” sorusunu araştırmasını sağlar.

``

Sanal kopya, ama dekor değil

Dijital ikiz yalnızca üç boyutlu bir santral görüntüsü değildir. Asıl değer; sıcaklık, basınç, yakıt debisi, titreşim ve elektrik üretimini açıklayan modellerdedir. Fiziksel ekipman veri üretir, model mevcut durumu tahmin eder, simülasyon gelecekteki seçenekleri karşılaştırır. Böylece bakım takvimi veya yük değişimi, gerçek ekipmana uygulanmadan önce sınanabilir. Modelin canlı verilerle düzenli güncellenmesi, onu sıradan bir simülasyondan ayıran temel özelliklerden biridir.

Veri hattında zaman damgalarının eşleşmesi ve sensörlerin kalibrasyonu kritiktir. Örneğin elektrik gücüyle yakıt debisini farklı dakikalardan eşleştirirseniz, model olmayan bir verim kaybını keşfedebilir. Dijital dedektifinizin önce saatini doğru ayarlaması gerekir!

Teorik temel: enerji ve bozulma

Basitleştirilmiş bir termik santral için net elektrik gücünü şöyle yazabiliriz:

Burada $Q_{in}$ yakıtın ısıl gücü, $P_{aux}$ yardımcı sistemlerin tüketimi, $f$ ise boyutsuz kirlenme göstergesidir. Güçlerin birimi MW olduğunda sonuç da MW olur. Kirlenmenin verimi düşürdüğünü varsayalım:

$\eta_0$ temiz ekipmanın verimi, $\alpha$ kirlenmeye duyarlılıktır. Saatlik ilerlemede basit bir bozulma modeli kullanabiliriz:

$L$ nominal kapasiteye göre yük oranıdır. Kare terimi, yüksek yükün kirlenmeyi daha hızlı artırdığı varsayımını temsil eder. Bu, evrensel bir fizik yasası değil; saha verileriyle doğrulanması gereken öğretici bir yaklaşımdır. Gerçek modeller sıcaklık dinamiklerini, ortam koşullarını ve ekipman sınırlarını da içerir.

Python ile üç alternatif gelecek

Aşağıdaki model, 100 MW nominal yakıt ısıl girdisini kullanır. Temizliğin kirlenmeyi yüzde 80 azalttığını, fakat dört saat üretim kaybettirdiğini varsayar. Her senaryo bağımsız bir kopyada çalışır; böylece biri diğerinin başlangıç durumunu değiştirmez.

from dataclasses import dataclass, replace

@dataclass
class Twin:
    fouling: float = 0.5
    eta0: float = 0.40
    alpha: float = 0.12
    auxiliary_mw: float = 2.0

    def forecast(self, load, hours=24, clean=False):
        if not 0 < load <= 1 or hours < 1:
            raise ValueError("Yük ve süre geçersiz")

        model = replace(self)
        if clean:
            model.fouling *= 0.2

        energy_mwh = 0.0
        for hour in range(hours):
            if clean and hour < 4:
                continue
            heat_mw = 100 * load
            efficiency = model.eta0 * (
                1 - model.alpha * model.fouling
            )
            power_mw = max(
                0, efficiency * heat_mw - model.auxiliary_mw
            )
            energy_mwh += power_mw  # Bir saatlik adım
            model.fouling = min(
                1, model.fouling + 0.004 * load**2
            )
        return round(energy_mwh, 1)

plant = Twin()
print("Tam yük:", plant.forecast(1.0))
print("Temizlik:", plant.forecast(1.0, clean=True))
print("Düşük yük:", plant.forecast(0.8))

Kod, saatlik gücü bir saatle çarparak toplam enerjiyi MWh cinsinden toplar. Temizlik sırasında üretimi sıfır kabul eder; bakımın yardımcı tüketimini ayrıca modellemez. Sonuçlar yaklaşık 849,1, 746,8 ve 671,2 MWh olur. Temizlik verimi yükseltse de ilk gün kaybedilen saatleri telafi edemez. Daha uzun ufukta sonuç değişebilir; ancak bu model arıza olasılığı hesaplamaz. Dolayısıyla düşük kirlenmeyi doğrudan “arıza önlendi” diye yorumlamak doğru değildir.

Sonuçları karara dönüştürmek

Uygulamada dört adımlı bir döngü kurabilirsiniz:

1. Ölç: Sensör verilerini topla; eksik, gecikmiş veya fiziksel olarak tutarsız kayıtları işaretle.
2. Kalibre et: Verim ve bozulma katsayılarını geçmiş işletme verileriyle belirle; ayrı dönemlerde doğrula.
3. Karşılaştır: Bakım tarihlerini, yük programlarını, yakıt giderlerini ve elektrik fiyatlarını birlikte değerlendir.
4. Denetle: Önerileri ekipman limitleri ve işletme prosedürleriyle kontrol ederek operatör onayına sun.

Tek bir tahmine güvenmek yerine parametreleri farklı aralıklarda çalıştırın. Sensör hatası veya beklenenden uzun bakım, kazanan senaryoyu değiştirebilir. Ayrıca santral ağına bağlantıda erişim kontrolü ve ağ ayrımı gerekir; deneysel model doğrudan kontrol komutları üretmemelidir.

Dijital ikizin hedefi kristal küre olmak değildir. Hedef, kararların varsayımlarını görünür kılmak ve seçenekleri güvenle karşılaştırmaktır. Santral gerçek dünyada çalışırken, fikirleriniz önce sanal dünyada ter döksün!

``

Önce amaç, sonra veri

Mahremiyet yalnızca bilgiyi başkalarından saklamak değildir; kişinin kendisi hakkındaki bilgilerin hangi bağlamda, kim tarafından ve nasıl kullanılacağını anlayabilmesidir. Güvenlik ise bu bilgileri yetkisiz erişimden korur. Aradaki fark önemlidir: Şifrelenmiş bir veritabanı, gereksiz yere toplanmış kamera görüntülerini etik hâle getirmez. Çelik kasa sağlamdır ama içine koyduğunuz her şey meşru olmayabilir.

Temel yaklaşım, amaçla sınırlılık ve veri minimizasyonudur. Her alan için şu soruyu sorun: “Bu veri olmadan tanımladığımız eğitim hizmeti gerçekten verilemez mi?” Öğrenme desteği amacıyla alınan verilerin sonradan reklam hedeflemesine aktarılması, öğrencinin beklediği bağlamı değiştirir. Ürün ekibinin merakı, tek başına yeterli gerekçe değildir.

Fayda ile risk aynı terazide

Kararları tartışmak için basit bir düşünce modeli kullanabiliriz:

Burada $D$ veri kümesi, $U(D)$ eğitimsel fayda, $R(D)$ mahremiyet riski, $a$ ise riske verilen ağırlıktır. Bu, hukuki uygunluğu hesaplayan sihirli bir formül değildir. Daha çok, “Biraz daha veri gerçekten anlamlı fayda sağlıyor mu?” sorusunu görünür kılar. Çocukların verilerinde risk değerlendirmesi özellikle ihtiyatlı yapılmalıdır.

Önemli nokta şudur: Bir yöntemin teknik olarak mümkün olması, pedagojik olarak gerekli olduğu anlamına gelmez. Özellikle sürekli gözetim, öğrencinin davranışlarını ve kendini ifade etme isteğini değiştirebilir.

Minimizasyonu kodun kapısına koymak

Aşağıdaki Python örneği, yalnızca izin verilen olayları kabul eder, ham öğrenci kimliğini anahtarlı bir takma kimliğe dönüştürür ve zamanı gün düzeyine indirger:

import hashlib
import hmac
import os
from datetime import datetime

KEY = bytes.fromhex(os.environ["PSEUDONYM_KEY_HEX"])
if len(KEY) < 32:
    raise ValueError("En az 32 baytlık anahtar gerekli")

ALLOWED = {"exercise_completed", "hint_requested"}

def minimize(event):
    if event["type"] not in ALLOWED:
        raise ValueError("Desteklenmeyen olay")

    student = str(event["student_id"]).encode("utf-8")
    reference = hmac.new(KEY, student, hashlib.sha256).hexdigest()
    day = datetime.fromisoformat(event["time"]).date().isoformat()
    return {
        "student_ref": reference,
        "event": event["type"],
        "day": day,
    }

Anahtar, güvenli biçimde üretilmiş rastgele baytların onaltılık gösterimi olarak yapılandırılmalı ve gizli tutulmalıdır. HMAC, düz kimlik özeti kullanımına göre tahmin saldırılarına karşı daha uygun bir yaklaşım sunar. Ancak takma adlandırma anonimleştirme değildir: Kayıtlar ilişkilendirilebilir ve hâlâ kişisel veri sayılabilir. Bu örnek ayrıca erişim kontrolü, silme veya hukuki uygunluk sağlamaz; yalnızca toplama sınırını gösterir.

Rıza, güç dengesi ve algoritmalar

“Kutuyu işaretledi, sorun çözüldü” yaklaşımı eğitimde özellikle kırılgandır. Öğrenci, derse katılmak için platformu kullanmak zorundaysa gerçek bir seçim yapabiliyor mu? Temel hizmet için gerekli işlemlerle isteğe bağlı analizler ayrılmalı; ret kararı öğrenciyi cezalandırmamalıdır.

KVKK, uygulanıyorsa GDPR ve ilgili eğitim mevzuatı kapsamında uygun hukuki dayanak belirlenmelidir; her işlem otomatik olarak rızaya dayanmaz. Çocuklara ve gerektiğinde velilere anlaşılır açıklamalar sunulmalıdır. Risk puanları da kader değildir: Bir öğrenciyi “başarısız olacak” diye etiketleyen model, önyargıları büyütebilir. Sonuçlar insan incelemesine, düzeltmeye ve itiraza açık olmalıdır.

Sorumluluk, yayına çıkınca bitmez

• Saklama: Her veri türü için gerekçeli süre belirleyin; “belki lazım olur” arşivi oluşturmayın.
• Erişim: Öğretmen, destek çalışanı ve yöneticiye yalnızca görevleri için gereken yetkiyi verin.
• Paylaşım: Tedarikçilerin veriyi hangi amaçlarla kullanabileceğini ve silebileceğini sözleşmelerle netleştirin.
• Denetim: Kayıtları, ihlal müdahalesini ve öğrenci taleplerini düzenli test edin.
• Adalet: Model hatalarının farklı öğrenci gruplarını eşitsiz etkileyip etkilemediğini değerlendirin.

Kısacası iyi eğitim teknolojisi, en çok veriyi toplayan değil, en az müdahaleyle anlamlı destek sağlayandır. Öğrenci bir veri madeni değil; hakları, merakı ve geleceği olan bir insandır.

``

Önce temel mantık: Güç bütçesi

Şarj istasyonlarının etiket güçlerini toplamak, altyapının gerçek ihtiyacını anlamak için yeterli değildir. Önemli olan, tesisin bağlantı kapasitesiyle o anda tüketilen diğer yükler arasındaki farktır. Dinamik yük dengeleme, ölçüm cihazlarından aldığı verilerle bu farkı düzenli olarak hesaplar ve araçlara ayrılabilecek toplam gücü günceller.

Basitleştirilmiş aktif güç modeli şöyledir:

Burada $P_{pay}$ güvenlik rezervidir. Her aracın aldığı güç için de şu sınırlar geçerlidir:

Örneğin tesis sınırı 120 kW, diğer tüketimler 45 kW ve rezerv 10 kW ise araçlara 65 kW kalır. Sekiz aracın her biri 11 kW isterse toplam talep 88 kW olur. Eşit paylaşımda araç başına yaklaşık 8,125 kW ayrılır; böylece toplam tüketim rezerv dahil belirlenen sınırı aşmaz.

Statik mi, dinamik mi, öngörülü mü?

Statik sistem, restoranın her akşam aynı sayıda masa açmasına benzer. Dinamik sistem müşteri yoğunluğunu izler; öngörülü sistem ise rezervasyon defterini de okur. Ancak hiçbir yöntem fiziksel bağlantı sınırını sihirli biçimde büyütmez.

Gücü adil dağıtmak: Ağırlıklı paylaşım

Eşit paylaşım anlaşılırdır, fakat ihtiyaçlar eşit olmayabilir. Yarım saat sonra ayrılacak servis aracı, gece boyunca park edecek araçtan daha yüksek öncelik alabilir. Ağırlıklı paylaşımda öncelikler sayısallaştırılır; araçların kabul edebileceği güç sınırları da korunur.

Aşağıdaki Python fonksiyonu bütçeyi ağırlıklara göre dağıtır. Sınırına ulaşan aracın kullanamadığı pay, sonraki turda diğerlerine aktarılır:

def paylastir(butce, araclar):
    if any(a['max_kw'] < 0 or a['agirlik'] <= 0 for a in araclar):
        raise ValueError('Güç negatif, ağırlık sıfır veya negatif olamaz.')

    kalan = max(0.0, butce)
    sonuc = [0.0] * len(araclar)
    aktif = [i for i, a in enumerate(araclar) if a['max_kw'] > 0]

    while aktif and kalan > 1e-6:
        toplam_agirlik = sum(araclar[i]['agirlik'] for i in aktif)
        tur_butcesi = kalan

        for i in aktif:
            arac = araclar[i]
            pay = tur_butcesi * arac['agirlik'] / toplam_agirlik
            ek = min(pay, arac['max_kw'] - sonuc[i])
            sonuc[i] += ek
            kalan -= ek

        aktif = [
            i for i in aktif
            if araclar[i]['max_kw'] - sonuc[i] > 1e-6
        ]

    return sonuc

araclar = [{'max_kw': 11.0, 'agirlik': 1.0} for _ in range(8)]
print(paylastir(65.0, araclar))

Bu örnek sekiz araç için yaklaşık 8,125 kW üretir. max_kw, yalnızca istasyonun etiketini değil, aracın ve bağlantının güncel sınırını temsil etmelidir. Fonksiyon sürekli güç paylaşımını gösterir; üretim sistemindeki haberleşme, hata yönetimi ve minimum akım koşullarını uygulamaz.

Sahada matematiğin yanına mühendislik koyun

Gerçek tesislerde toplam kW sınırı tek başına yeterli değildir. Özellikle tek fazlı araçlar, toplam kapasite uygun görünürken bir fazı aşırı yükleyebilir. Bu nedenle faz akımları, kablo sınırları, koruma elemanları ve gerektiğinde görünür güç de izlenmelidir. Yazılım, elektriksel korumanın yerine geçmez.

AC şarjda izin verilen minimum akımın altında kesintisiz paylaşım mümkün olmayabilir. Böyle durumlarda bazı oturumları sırayla bekletmek gerekir. Ölçüm gecikmesine karşı rezerv bırakmak, komut değişimlerini yumuşatmak ve iletişim kesildiğinde güvenli sınırlara dönmek de önemlidir.

Optimizasyonun gerçek hedefi

Güç, anlık hızdır; enerji ise zaman boyunca biriken miktardır. Sabit güçte bataryaya aktarılan yaklaşık enerji $E=\eta P\Delta t$ ile hesaplanır. Burada $\eta$ verim, $\Delta t$ saat cinsinden süredir. Ayrılış zamanına kadar gereken enerjiyi tamamlamak, her aracı sürekli maksimum güçte tutmaktan daha anlamlıdır.

Ucuz saatlere kaydırma, güneş üretimini değerlendirme ve tesisin tepe talebini azaltma aynı planın parçaları olabilir. Fakat düşük öncelikli araçların sürekli beklememesi için bekleme süresi de hesaba katılmalıdır. Başarılı yük dengeleme, en yüksek anlık gücü değil; güvenli, adil ve zamanında tamamlanan şarjı hedefler.

Çatınızdaki güneş panelleri öğle vakti elektrik üretirken şehir şebekesi kendi ritminde çalışmaya devam eder. Peki bu iki kaynak birbirine bağlandığında neden elektriksel bir kakofoni oluşmaz? Çünkü arada, enerjiyi dönüştürmenin yanında şebekenin temposunu izleyen bir inverter bulunur. Bu yazıda küçük üreticilerin dev elektrik orkestrasına nasıl katıldığını, kontrol teorisi ve küçük bir Python deneyiyle keşfedeceğiz. ``

Önce aynı dili konuşmak gerekir

Güneş paneli doğru akım, yani DC üretir. Şebeke ise Türkiye’de nominal olarak 50 Hz alternatif akımla çalışır. İnverter, DC enerjiyi anahtarlama elemanlarıyla AC’ye dönüştürür; filtreler de anahtarlamanın yüksek frekanslı bileşenlerini azaltır. Ancak yalnızca sinüs benzeri bir dalga üretmek yetmez: bağlantı noktasındaki gerilim, frekans ve faz ilişkisi kontrol edilmelidir.

Önemli ayrıntı şudur: Yaygın şebeke takip eden inverterler, güçlü şebekeye kendi gerilimlerini zorla dayatmaz. Şebeke gerilimini referans alarak verecekleri akımı düzenler. Kalabalıkta yürüyüş temposunu tutturmak gibi düşünün; herkesi kendi adımınıza uydurmaya çalışmazsınız.

Faz neden bu kadar önemli?

İki AC büyüklüğünün faz farkı, enerjinin nasıl aktarıldığını belirler. Tek fazlı, sinüzoidal temel bileşen için aktif ve reaktif güç ilişkileri şöyledir:

Burada $V$ ve $I$ etkin değerler, $\varphi$ ise gerilim ile akım arasındaki faz farkıdır. Aktif güç $P$, işe dönüşen enerji akışını temsil eder. Reaktif güç $Q$ ise elektrik ve manyetik alanlarla ilişkili alışveriştir; uygun kontrol edildiğinde yerel gerilim yönetimine yardımcı olabilir.

Birçok inverter, aktif güç aktarırken akımı gerilimle aynı fazda tutmaya çalışır. Gerektiğinde reaktif güç de sağlar. Ancak bu görevler bağımsız sınırsız düğmeler değildir: inverterin akım ve görünür güç kapasitesi paylaşılır. Daha fazla reaktif destek, bazı koşullarda aktarılabilecek aktif gücü azaltabilir.

PLL: Elektronik bir ritim dedektifi

Faz kilitlemeli döngü, yani PLL, ölçülen şebeke geriliminden faz açısını tahmin eder. Yaygın yaklaşım, gerilim bileşenlerini dönen bir koordinat sistemine taşımaktır. Tahmin doğruysa uygun eksendeki hata yaklaşık sıfıra iner. PI denetleyici bu hatadan frekans düzeltmesi üretir:

Aşağıdaki örnek, ideal ve normalize edilmiş iki dik gerilim bileşeniyle çalışan basitleştirilmiş bir PLL simülasyonudur. Gerçek donanıma komut göndermez.

import math

dt = 0.0005
theta = 0.0
integral = 0.0
omega_ref = 2 * math.pi * 50
kp, ki = 80.0, 1600.0

for k in range(3000):
    t = k * dt
    grid_phase = 2 * math.pi * 50.1 * t + 0.4
    alpha = math.cos(grid_phase)
    beta = math.sin(grid_phase)

    error = beta * math.cos(theta) - alpha * math.sin(theta)
    integral += error * dt
    omega = omega_ref + kp * error + ki * integral
    theta = (theta + omega * dt) % (2 * math.pi)

    if k % 1000 == 0:
        print(f"t={t:.2f}s, tahmin={omega / (2 * math.pi):.3f}Hz")

error, gerçek faz ile tahmin arasındaki farkın sinüsüdür. İntegral terimi kalıcı frekans sapmasını giderir; theta ise tahmin edilen açıyı ilerletir. Tahmin, bu ideal koşullarda 50,1 Hz’e yaklaşır. Kazançlar örnektir: gerçek tasarımda gürültü, harmonikler, gecikme ve sınırlandırmalar değerlendirilir. Tek fazlı uygulamalarda dik bileşenin ayrıca oluşturulması gerekir.

Senkronizasyon yalnızca başlangıçtır

Panel tarafındaki MPPT algoritması en verimli çalışma noktasını ararken, DC bağlantı gerilimi kontrolü enerji dengesini yönetir. Daha hızlı akım döngüsü de şebekeye verilen akımı referansa uydurur. Bu katmanların bant genişlikleri uyumlu seçilmezse kontrolcüler birbirinin işine karışabilir.

Şebeke oluşturan kontrol de sınırsız güç üretmez; enerji kaynağı ve akım sınırları hâlâ belirleyicidir. Özellikle çok sayıda inverter bağlandığında, şebekenin empedansı ve kontrol döngülerinin etkileşimi kararlılık analizinin merkezine yerleşir.

Güvenli bağlantı, iyi ritimden fazlasıdır

Şebeke kesildiğinde üretimin kontrolsüz biçimde hattı beslememesi için adalanma koruması gerekir. Gerilim ve frekans korumaları, topraklama, bağlantı izinleri ve yerel şebeke kuralları da entegrasyonun parçasıdır. Gerçek bağlantı sertifikalı ekipman ve yetkin uzmanlarla yapılmalıdır. Kısacası başarılı entegrasyon; ritmi yakalamak, doğru miktarda enerji aktarmak ve gerektiğinde güvenle sahneden çekilmektir.

Bir insansız aracın başarılı olması, yalnızca hedefe ulaşmasına değil, geri dönecek enerjiyi de saklamasına bağlıdır. Pil göstergesi yüzde yirmiyi gösterirken son bir fotoğraf çekmek cazip gelebilir; ancak algoritmanın romantizme değil, enerji bütçesine ihtiyacı vardır. Peki görev değeri, uçuş süresi ve güvenlik nasıl birlikte optimize edilir? ``

Önce enerjinin muhasebesini tutalım

Pil kapasitesi, görev boyunca kullanılabilecek enerjiyle aynı şey değildir. Sıcaklık, yaşlanma, yüksek akım çekişi ve gerilim düşümü gerçek kapasiteyi etkiler. Bu nedenle yalnızca nominal amper-saat değerine bakmak yanıltıcıdır. Enerji yaklaşık olarak gerilim ve kapasitenin çarpımıyla hesaplanabilir; ancak planlama sırasında ölçümlerle güncellenen bir tahmin kullanmak daha güvenilirdir.

Anlık güç tüketimi $P(t)=V(t)I(t)$ şeklindedir. Güç watt, zaman saniye olduğunda tüketilen enerji:

Buradaki önemli ayrım şudur: güç, tüketim hızıdır; enerji ise toplam harcamadır. Daha güçlü çalışan bir motor, görevi yeterince hızlı bitirirse toplamda daha az enerji tüketebilir. Tersine, yavaş ilerlemek elektroniklerin daha uzun süre açık kalmasına neden olabilir.

Örneğin bir kara aracında aerodinamik güç, uygun koşullarda hızın yaklaşık küpüyle büyür. Drone içinse askıda kalma, ileri uçuş ve tırmanış farklı modeller gerektirir. Tek bir “kilometre başına tüketim” sabiti her platforma uymaz.

Görevi bir optimizasyon problemine çevirmek

Her alt göreve bir ödül $r_i$, enerji maliyeti $e_i$ ve süre $t_i$ atayalım. Seçim değişkeni $x_i\in{0,1}$ olsun. Amaç, toplam görev değerini artırmaktır:

Enerji kısıtı ise şöyledir:

Benzer biçimde toplam süre, dönüş süresi çıkarılmış zaman bütçesini aşmamalıdır. Dönüş enerjisi planlı dönüş içindir; rezerv ise tahmin hataları ve beklenmeyen koşullar için ayrı tutulur.

Bu sade model, iki kısıtlı sırt çantası problemidir. Görev sırası ve aralarındaki mesafeler de karar değişkeniyse rota optimizasyonu devreye girer. Dolayısıyla en kısa yol, en değerli veya en güvenli görev planı olmayabilir.

Python ile enerji ve süre bütçelemesi

Aşağıdaki dinamik programlama örneği, bağımsız görevlerden en değerli birleşimi seçer. Maliyetler hareket ve sensör tüketimini içeren önceden hesaplanmış değerlerdir. Görevler arası geçiş maliyetinin seçim sırasına bağlı olduğu gerçek rotalar için bu varsayım yeterli değildir.

from math import ceil, floor

gorevler = [
    ("harita", 14, 8, 6),
    ("ornek", 18, 10, 9),
    ("tarama", 30, 16, 12),
    ("fotograf", 9, 5, 4),
]

adim = 0.5  # Wh
enerji_limiti = floor((80 - 12 - 8) / adim)
sure_limiti = 30 - 5  # dakika; dönüş hariç
# Anahtar: (enerji dilimi, dakika)
# Değer: (toplam ödül, seçilen görevler)
dp = {(0, 0): (0, [])}

for ad, enerji, sure, odul in gorevler:
    yeni = dict(dp)
    for (e, t), (puan, secim) in dp.items():
        ne = e + ceil(enerji / adim)
        nt = t + sure
        if ne <= enerji_limiti and nt <= sure_limiti:
            aday = (puan + odul, secim + [ad])
            if aday[0] > yeni.get((ne, nt), (-1, []))[0]:
                yeni[(ne, nt)] = aday
    dp = yeni

print(max(dp.values(), key=lambda sonuc: sonuc[0]))

Algoritma enerji maliyetlerini yukarı, bütçeyi aşağı yuvarlayarak enerji açısından ihtiyatlı davranır. Süreler burada tam dakika kabul edilmiştir. Sonuç, 19 puanlık harita, örnek ve fotoğraf birleşimidir. Bütçenin tamamını tüketmek zorunlu değildir; amaç pili boşaltmak değil, kısıtlar altında en yüksek değeri üretmektir.

Planı sahada yeniden hesaplamak

Başlangıçta kusursuz görünen plan, karşı rüzgârla birkaç dakika içinde eskir. Model öngörülü kontrol yaklaşımında araç belirli aralıklarla kalan enerjiyi tahmin eder, kısa bir planlama ufkunu optimize eder ve yalnızca ilk kararı uygular. Ardından ölçümlerle yeniden planlar.

Pil doluluk tahmini için akım entegrasyonu, gerilim modeliyle birleştirilebilir; Kalman filtresi bu birleşimin yaygın yöntemlerinden biridir. Planlayıcı ayrıca dönüş maliyetini mevcut konuma göre güncellemelidir. Beklenen tüketim yerine ihtiyatlı senaryolarla hesaplanan tüketim kullanmak, özellikle rüzgârlı görevlerde güvenliği artırır.

En iyi sistem üç metriği birlikte izler: tamamlanan görev değeri, enerji tahmin hatası ve dönüşte kalan rezerv. Böylece optimizasyon, yalnızca simülasyonda güzel görünen bir sayı olmaktan çıkar; ölçülebilir ve güvenli bir operasyon politikasına dönüşür.

Önce Mantık: Emir Defteri Nedir?

Emir defteri, gerçekleşmeyi bekleyen alış ve satış emirlerini tutar. Alış tarafındaki en yüksek fiyat en iyi alış, satış tarafındaki en düşük fiyat ise en iyi satış olarak adlandırılır. Aralarındaki fark, yani spread:

Bir limit alış emri, ödemeye razı olduğunuz azami fiyatı belirtir. Limit satış emri ise kabul edeceğiniz asgari fiyatı söyler. Alıcının limiti satıcının fiyatına eşit veya yüksekse eşleşme mümkündür. Piyasa emri fiyat sınırı koymadan mevcut likiditeyi tüketir; büyük emirlerde bu nedenle kayma oluşabilir.

Örneğin satış defterinde 100 USDT’den iki, 101 USDT’den üç token bulunsun. Dört tokenlık, 101 USDT limitli alış emri önce iki tokenı 100’den, sonra iki tokenı 101’den alır. İşlem fiyatı, bu modelde defterde bekleyen emrin fiyatıdır.

Kim Önce İşlem Görür?

Yaygın yaklaşım fiyat-zaman önceliğidir: Daha iyi fiyat önce gelir; aynı fiyatta daha önce kabul edilen emir önceliklidir. Bu yüzden her fiyat seviyesinde bir FIFO kuyruğu tutulabilir.

Burada $L$, fiyat seviyesi sayısıdır. Ağaç kullanılan bir tasarımda en iyi seviyeye işaretçi tutulabilir; seviyenin içindeki kuyruk başını kaldırmak ise $O(1)$ maliyetlidir.

Fiyat ve miktarlar genellikle kayan noktalı sayılar yerine tam sayı olarak saklanır:

Böylece yuvarlama sürprizleri yerine açık fiyat adımları ve miktar kuralları kullanılır.

Milisaniyelik İşlem Hattı

Tipik akış şu istasyonlardan geçer:

1. Ağ geçidi: Kimlik doğrulama, mesaj biçimi ve hız sınırları kontrol edilir.
2. Risk kontrolü: Bakiye, minimum miktar ve fiyat adımı doğrulanır; gerekli varlık rezerve edilir.
3. Sıralayıcı: Kabul edilen emir ve iptal komutlarına kesin bir sıra numarası atanır.
4. Motor: Komutlar bu sırayla uygulanır; gerçekleşmeler ve defter değişiklikleri üretilir.

Aynı defteri birçok iş parçacığının gelişigüzel değiştirmesi yarış koşulları yaratır. Yaygın çözüm, her defter için tek yazarlı deterministik işlemektir. Ölçekleme farklı işlem çiftlerine dağıtılarak yapılabilir; birden fazla defter aynı süreçte de çalışabilir.

Önceliğin hakemi istemci saati değil, sunucunun kabul sırasıdır. Aksi hâlde bilgisayarının saatini değiştiren kullanıcı sırada öne geçmeye çalışabilir!

Küçük Bir Eşleştirme Prototipi

Aşağıdaki Python kodu, önceden doğrulanmış bir limit alış emrini satış kuyruklarıyla eşleştirir:

from collections import deque
from dataclasses import dataclass

@dataclass
class Order:
    oid: int
    price: int
    qty: int

def match_buy(limit, qty, asks):
    trades = []
    while qty > 0 and asks:
        price = min(asks)
        if price > limit:
            break
        queue = asks[price]
        maker = queue[0]
        filled = min(qty, maker.qty)
        trades.append((maker.oid, price, filled))
        qty -= filled
        maker.qty -= filled
        if maker.qty == 0:
            queue.popleft()
        if not queue:
            del asks[price]
    return trades, qty

asks = {
    10000: deque([Order(1, 10000, 2)]),
    10100: deque([Order(2, 10100, 3)]),
}
trades, remaining = match_buy(10100, 4, asks)

Fiyat adımı 0,01 USDT kabul edilirse 10000, 100 USDT’yi temsil eder. Kod kısmi gerçekleşmeleri işler ve boş seviyeleri kaldırır. Ancak min(asks) her turda seviyeleri tarar: Bu bir öğretim örneğidir, üretim motoru değildir. Eşleşmeyen miktar, GTC limit emrinde alış defterine eklenir; IOC emrinde iptal edilir.

Hız Yetmez: Çökünce Ne Olacak?

Motorun bellekte çalışması, kayıtların unutulabileceği anlamına gelmez. Komut günlüğü ve periyodik snapshot kullanılarak durum yeniden oluşturulur. Dışarıya kesin kabul veya işlem sonucu bildirilmeden önce gereken kalıcılık garantisi sağlanmalıdır. Günlük senkronizasyonu ve çoğaltma tercihleri gecikmeyi etkiler.

Yeniden oynatma aynı komutlardan aynı sonucu üretmelidir. Emir kimlikleriyle yinelenen istekler ayıklanır; piyasa verisi sıra numaralarıyla yayınlanır, kayıp mesajlar snapshot üzerinden tamamlanır. Bakiye muhasebesi de gerçekleşme olaylarını güvenilir biçimde işlemelidir.

Son olarak yalnızca ortalama gecikmeyi ölçmeyin: p99 gecikmesi, yoğunluk altında kuyruk büyümesi ve iptal performansı da önemlidir. İyi motor, hızlı bir çöpçatan olduğu kadar, sırası şaşmayan titiz bir muhasebecidir.