TRON Enerji Kiralamasını API ile Nasıl Otomatikleştirirsiniz
Enerji Kiralamasını Otomatikleştirmek Neden Şart
Bir sıcak cüzdan, bir borsa para çekme motoru veya kullanıcılar adına TRC-20 transferleri tetikleyen bir kontrat çalıştırıyorsanız, sıkıntıyı zaten biliyorsunuzdur: bir işlem tetiklendiği anda TRON enerjisinin hazır olması gerekir. Bir arayüz üzerinden enerjiyi elle doldurmak, günde birkaç transferin ötesine geçtiğinizde ölçeklenmez. Pencereyi kaçırırsanız işlem gönderici adresten TRX yakar, çoğu zaman önceden kiralanmış enerjiden çok daha yüksek bir maliyetle.
Çözüm, arka ucunuz bir işlemi yayınlamak üzereyken kiralama API'sini çağırmaktır, böylece enerji insan müdahalesi olmadan programatik olarak sağlanır. Bu makale, bunu tronenergyrent.com üzerinden tam olarak nasıl yapacağınızı adım adım anlatıyor: gerçek istek yapısı, asenkron sipariş yaşam döngüsü, mantıklı süre tercihleri ve servisinize doğrudan bırakabileceğiniz çalışan bir Python örneği.
API Zincir Üzerinde Aslında Ne Yapar
Kod yazmadan önce, zincir üzerindeki mekanizmaları anlamak, körlemesine hata ayıklamamak için faydalı olur.
TRON'un kaynak modeli hesaplamayı (enerji) işlem boyutundan (bandwidth) ayırır. Standart bir USDT TRC-20 transferi, alıcı zaten USDT tuttuğunda yaklaşık 65,000 enerji tüketir; alıcının USDT bakiyesi sıfır olduğunda ise yaklaşık 130,000 enerji tüketir. Gelen ilk transfer, bakiye girdisinin oluşturulmasının depolama maliyetini öder; bu yüzden maliyet tamamen alıcıya bağlıdır, göndericiye değil. Bir transfer için bandwidth kullanımı yaklaşık 345 bayttır; bu miktar, çoğu hesabın günlük ücretsiz kotasından karşılayabileceği kadar küçüktür.
Kiralama API'sini çağırdığınızda servis kendi TRX'ini kilitler ve ortaya çıkan enerjiyi belirttiğiniz adrese Stake 2.0'dan DelegateResourceContract kullanarak devreder. Devretme adrese özgüdür ve zaman sınırlıdır. Kiralama süresi dolduğunda enerji sağlayıcı tarafından otomatik olarak geri alınır.
Önemli bir ayrıntı: kiralama asenkrondur. API çağrısı bir orderId ve PAID_BY_USER durumuyla hemen geri döner; ancak zincir üzerindeki devretme işlemi arka planda yayınlanır ve genellikle birkaç saniye içinde zincire iner. Entegrasyonunuz ilk yanıtı, siparişin kabul edildiğinin ve ödendiğinin onayı olarak görmeli, ardından durum ENERGY_DELEGATED değerine geçene kadar sipariş ayrıntıları uç noktasını sorgulamalıdır.
Doğru Kiralama Süresini Seçmek
API, dört izinli değere sahip bir period parametresi kabul eder: 1h, 1d, 3d, 30d. Fiyatlar zincir üzerindeki enerji piyasasıyla birlikte değişir ve gün içinde kayar; bu yüzden canlı rakamlar her zaman fiyatlandırma sayfasında bulunur. Göreli sıralama sabittir: 1h çağrı başına en ucuzudur, 30d ise aynı adresten çok sayıda transfere bölündüğünde en ucuzudur.
Giden her transfer için bir kiralama tetiklediğiniz olay odaklı bir sistemde, neredeyse her zaman 1h kademesi doğru tercihtir. En düşük mutlak maliyeti ödersiniz ve enerji, devredilmesinden saniyeler sonra tüketilir. 1d ve daha uzun kademeler, öngörülebilir toplu iş yükleri çalıştırdığınızda, örneğin gecelik bir ödeme işi gibi, ve API'yi onlarca kez çağırmak yerine büyük bir enerji bloğunu bir kez kiralamak istediğinizde mantıklıdır.
Sisteminiz aynı adresten saatte sürekli 20-30'dan fazla transfer tetikliyorsa, beklenen hacminizi karşılayacak boyutta bir 1d bloğu kiralamak, transfer başına çağrılardan daha temiz olur. Peşin maliyet artar, ancak API ek yükü ve zincir üzerindeki onay gecikmesi sıcak yoldan kaybolur.
Kimlik Doğrulama ve İstek Yapısı
Kiralama uç noktası şu adreste bulunur:
GET https://api.tronenergyrent.com/place-energy-order
Bu, sorgu parametreleri olan düz bir GET isteğidir. Kimlik doğrulama, kayıt olup hesabınıza para yükledikten sonra gösterge panelinden oluşturduğunuz apiKey sorgu parametresidir. Bu uç nokta için başlık tabanlı kimlik doğrulama veya JSON istek gövdesi yoktur.
Parametreler şunlardır:
apiKey(zorunlu): gösterge panelinden alınan API anahtarınız.period(zorunlu): kiralama süresi, şunlardan biri:1h,1d,3d,30d.energyAmount(zorunlu): ne kadar enerji devredileceği. Minimum15000. Zaten USDT tutan bir alıcıya yapılan tek bir standart USDT transferi için65000güvenli rakamdır; yeni bir USDT sahibine yapılan ilk transfer için130000kullanın.destinationAddress(zorunlu): devredilen enerjiyi alacak TRON adresi (base58check,Tile başlar).preActivateDestinationAddress(isteğe bağlı, varsayılan0): hedef adres hiç TRX almamışsa ve dolayısıyla zincir üzerinde etkinleştirilmemişse1olarak ayarlayın. Servis o zaman enerjiyi devretmeden önce adresi etkinleştirmek için ön ödemeli bakiyenizden1.5 TRXgönderir. Adres zaten etkinse, ek maliyetten kaçınmak için bunu0olarak bırakın.
Yanıt, siparişin başarılı olup olmadığına bakılmaksızın her zaman 200 HTTP durumuyla döner. HTTP durumu yerine JSON gövdesinin status alanına göre dallanın. Başarılı bir gövde şöyle görünür:
{
"status": "SUCCESS",
"errorCode": null,
"errorDescription": null,
"requestId": "2651eacd-2428",
"payload": {
"orderId": "128de799-501e-44b2-8d6f-1fa825c2deed",
"totalPriceSun": 5662800,
"totalPriceTrx": 5.6628,
"state": "PAID_BY_USER"
}
}
Hata gövdesinde status: "ERROR", makinece okunabilir bir errorCode ve insanca okunabilir bir errorDescription bulunur:
{
"status": "ERROR",
"errorCode": "INVALID_ENERGY_AMOUNT",
"errorDescription": "energyAmount is less than 15000",
"requestId": "71431087-4",
"payload": null
}
Her iki dalda da her zaman requestId değerini günlüğe yazın. Bir kiralamayı izlemek için destekten yardım istemeniz gerekirse, aradıkları kimlik budur.
Sipariş Yaşam Döngüsü
Yükteki state alanı küçük ve sabit bir sırayla ilerler:
PAID_BY_USER: başlangıç durumu, sipariş bakiyenizden ödendi ancak henüz zincir üzerinde bir işlem gerçekleşmedi.WAITING_DELEGATION: servis siparişi aldı ve devretme işlemini hazırlıyor.ENERGY_DELEGATED: devretme işlemi zincire indi. Hedef adres artık kiralanmış enerjiyi tutuyor ve bir sonraki giden işlemde harcayabilir.ERROR_DELEGATION: devretme bir nedenden ötürü başarısız oldu. Nadirdir ancak yoğun ağ tıkanıklığı sırasında mümkündür.CANCELLED: sipariş iptal edildi ve fonlar bakiyenize iade edildi.
Geçerli durumu kontrol etmek için şunu çağırın:
GET https://api.tronenergyrent.com/single-order-details?apiKey=YOUR_API_KEY&orderId=ORDER_ID
Yanıt, geçerli state değeri payload içinde olmak üzere aynı status / errorCode / payload zarfını kullanır. Siparişi verdikten sonra bunu her bir-iki saniyede bir sorgulayın ve TRC-20 transferinize yalnızca ENERGY_DELEGATED gördükten sonra devam edin. Pratikte bu genellikle bir veya iki sorgu olur.
Çalışan Bir Python Entegrasyonu
İşte minimal ama üretim biçimindeki bir desen. Kiralamayı yapar, devretme zincire inene kadar sorgular ve bir şey ters giderse net bir hata gösterir.
import logging
import time
import requests
API_BASE = "https://api.tronenergyrent.com"
API_KEY = "your_api_key_here"
ENERGY_FOR_TRANSFER = 65_000 # use 130_000 if recipient has zero USDT balance
HTTP_TIMEOUT_SECS = 10
POLL_INTERVAL_SECS = 1
POLL_TIMEOUT_SECS = 30
def place_order(destination_address: str, period: str = "1h",
energy_amount: int = ENERGY_FOR_TRANSFER) -> dict:
resp = requests.get(
f"{API_BASE}/place-energy-order",
params={
"apiKey": API_KEY,
"period": period,
"energyAmount": energy_amount,
"destinationAddress": destination_address,
"preActivateDestinationAddress": 0,
},
timeout=HTTP_TIMEOUT_SECS,
)
resp.raise_for_status()
body = resp.json()
if body.get("status") != "SUCCESS":
raise RuntimeError(
f"place-energy-order failed: {body.get('errorCode')} "
f"({body.get('errorDescription')}) requestId={body.get('requestId')}"
)
return body["payload"]
def wait_for_delegation(order_id: str) -> dict:
deadline = time.monotonic() + POLL_TIMEOUT_SECS
while time.monotonic() < deadline:
resp = requests.get(
f"{API_BASE}/single-order-details",
params={"apiKey": API_KEY, "orderId": order_id},
timeout=HTTP_TIMEOUT_SECS,
)
resp.raise_for_status()
body = resp.json()
if body.get("status") != "SUCCESS":
raise RuntimeError(
f"single-order-details failed: {body.get('errorCode')} "
f"({body.get('errorDescription')})"
)
state = body["payload"]["state"]
if state == "ENERGY_DELEGATED":
return body["payload"]
if state == "ERROR_DELEGATION":
raise RuntimeError(f"Delegation failed for order {order_id}")
if state == "CANCELLED":
raise RuntimeError(f"Order {order_id} was cancelled")
time.sleep(POLL_INTERVAL_SECS)
raise TimeoutError(f"Order {order_id} did not reach ENERGY_DELEGATED in {POLL_TIMEOUT_SECS}s")
def rent_energy(destination_address: str) -> dict:
placed = place_order(destination_address)
logging.info(
"Order placed: id=%s priceSun=%s priceTrx=%s",
placed["orderId"], placed["totalPriceSun"], placed["totalPriceTrx"],
)
delegated = wait_for_delegation(placed["orderId"])
logging.info("Order delegated: id=%s", delegated["orderId"])
return delegated
Vurgulanmaya değer birkaç nokta var. Açık status == "SUCCESS" kontrolü önemlidir çünkü HTTP durumu her zaman 200'dür; dolayısıyla tek başına resp.raise_for_status() size gerçek sonuç hakkında hiçbir şey söylemez. Sorgulama döngüsünün sıkı bir zaman aşımı vardır; böylece takılı kalan bir sipariş transfer hattınızı süresiz olarak engelleyemez. state üzerindeki dallanma, üç son sonucu (ENERGY_DELEGATED, ERROR_DELEGATION, CANCELLED) genel bir "başarılı değil" yaklaşımına güvenmek yerine açıkça ele alır.
Transfer iş akışınızda önce rent_energy() fonksiyonunu çağırın, ardından TRC-20 transferini yayınlayın. İşlem sırası önemlidir: önce yayınlarsanız işlem göndericiden TRX yakar, çünkü devretme henüz zincire inmemiştir.
Ön Ödemeli Bakiyenizi Boyutlandırma
Kiralama maliyeti, tronenergyrent.com hesabınızda tuttuğunuz ön ödemeli bakiyeden düşülür. Bakiye bir eşiğin altına düştüğünde bir uyarı veya otomatik bakiye yüklemesi kurun. Mantıklı bir alt sınır, iki saatlik tepe hacmini karşılayan miktardır.
Geçerli bakiyeyi programatik olarak okumak için:
GET https://api.tronenergyrent.com/account-info?apiKey=YOUR_API_KEY
Yük, geçerli bakiyenizi ve hesap durumunuzu içerir. Bunu izleme yığınınıza bağlayın; sabah 2'de tükenmiş bir bakiyeyle bir daha asla şaşırmazsınız. tronenergyrent.com bakiyenize minimum yüklemenin 10 TRX olduğunu unutmayın.
Uygulamada Hata İşleme
Üretimde en sık üç başarısızlık modu ortaya çıkar. Aşağıdaki hata kodları gerçek API'den gelir ve güvenle bunlara göre dallanabilirsiniz.
INSUFFICIENT_BALANCE: ön ödemeli bakiyeniz istenen kiralamayı ve varsa ön etkinleştirmeyi karşılayacak kadar düşük. Yeniden denemeyin, yeniden denemek bunu çözmez. Bunu özel olarak yakalayın ve bir uyarı veya bakiye yükleme akışını tetikleyin.requestIddeğerini uyarı yükünüze ekleyin.INVALID_ADDRESS:destinationAddress, sunucuda base58check çözümlemesini geçemedi. Sisteminiz adresleri dinamik olarak, örneğin kullanıcı tarafından sağlanan girdiden oluşturuyorsa, API'yi çağırmadan önce yerel olarak doğrulayın.tronpyPython kitaplığında bunun içinis_address()vardır; hatalı girdiyi istemci tarafında reddetmek, gidiş dönüşü beklemekten daha hızlıdır.INACTIVE_DESTINATION_ADDRESS_ERROR: hedef adres zincir üzerinde hiç etkinleştirilmemiş ve servisten etkinleştirmesini istemediniz. Düzeltmek için ya adrese başka bir yerden küçük bir miktar TRX ile ön finansman yapın, ya da bir sonraki çağrıdapreActivateDestinationAddress=1geçirin, böylece servis adresi1.5 TRXkarşılığında etkinleştirir.
Daha ince bir durum: aynı hedef için aynı anda kiralama yapan birden fazla işçiniz varsa ORDER_IS_ALREADY_IN_PROGRESS dönebilir. Çözüm API tarafında değil, süreç tarafındadır. Hedef adrese göre anahtarlanmış ve devretme tamamlanana kadar tutulan bir dağıtık kilit (Redis gayet iyi çalışır) alın.
Zincir Üzerinde Doğrulama
Çoğu entegrasyon için /single-order-details uç noktasını ENERGY_DELEGATED durumuna kadar sorgulamak yeterlidir. Ekstra güvence isterseniz, devretme zincire indikten sonra TRON tam düğümünü doğrudan da sorgulayabilirsiniz:
GET https://api.trongrid.io/v1/accounts/{destinationAddress}
Yanıt, dış adreslerden ona devredilen enerji dahil olmak üzere adresin geçerli kaynak durumunu içerir. Tam alan adı geçerli Stake 2.0 görünümüne bağlıdır, bu nedenle bunu bağlarken canlı TRON HTTP API belgelerine başvurun. Transferi engellemek yerine bir uyarı kaydı düşen yumuşak bir kontrol olarak, kiralama API'sinin kendisinin alt akışında nadiren bir şey ters gittiğinde faydalı bir uyarı sinyalidir.
Bu ek kontrol, kiralamanın API'de başarılı göründüğü ama zincir üzerinde başka bir şeyin ters gittiği nadir durumda saatlerce süren hata ayıklamadan sizi kurtaracaktır.