#shareyourthinking
shareyourthinking
185 views
3 සාකච්ඡා කරමින්
උණුසුම්
නවතම
Smart contract attestation dependency reliability commitment
Been thinking about this for a few days because I Have added thirdparty dependencies to smart contracts before and the question always hits the same wall: what happens to my protocol if the dependency goes down.
Newton requires applications to validate a BLS attestation in their smart contract before executing No valid attestation no execution.
Thats the enforcement mechanism and also a hard dependency.
Once a protocol deploys that requirement into an immutable contract it has committed to Newtons operator network being available for every transaction that coNtract will ever process.
Thats not a criticism. Its a design choice with real implications.
A protocol integrating Newton is no longer just trusting its own code.
Its trusting that a quorum of staked operators will evaluate policies and produce attestations for every transaction indefinitely. The whitepaper addresses censorship via forceinclusion. It does N0t address what happens during genuine operator network degradation not censorship just underperformance or partial oUtage.
#newt
I actually think the reliability commitment is the question that matters most for protocol teams evaluating Newton more than the compliance feature set. Adding a dependency to a smart contract is permanent in a way that adding one to a web service is Not.
#NEWT
What I have n0t figured out is whether theres a graceful degradation mode some way a protocol could fall back during operator outages rather than halting entirely.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt
Been thinking about this for a few days because I Have added thirdparty dependencies to smart contracts before and the question always hits the same wall: what happens to my protocol if the dependency goes down.
Newton requires applications to validate a BLS attestation in their smart contract before executing No valid attestation no execution.
Thats the enforcement mechanism and also a hard dependency.
Once a protocol deploys that requirement into an immutable contract it has committed to Newtons operator network being available for every transaction that coNtract will ever process.
Thats not a criticism. Its a design choice with real implications.
A protocol integrating Newton is no longer just trusting its own code.
Its trusting that a quorum of staked operators will evaluate policies and produce attestations for every transaction indefinitely. The whitepaper addresses censorship via forceinclusion. It does N0t address what happens during genuine operator network degradation not censorship just underperformance or partial oUtage.
#newt
I actually think the reliability commitment is the question that matters most for protocol teams evaluating Newton more than the compliance feature set. Adding a dependency to a smart contract is permanent in a way that adding one to a web service is Not.
#NEWT
What I have n0t figured out is whether theres a graceful degradation mode some way a protocol could fall back during operator outages rather than halting entirely.
#ShareYourThinking $LAB $HMSTR
@NewtonProtocol $NEWT #Newt
Faucet claim limits determine whether Testnet actually tests anything close to Real Usage or just confirms the pipeline works at Trivial size.
#baby A faucet that hands out a fixed Small amount per wallet is fine for confirming deposit to borrow mechanics function. Its not fine for stress Testing what happens to Health factor calculations Liquidation Triggers or Aave v4 pool behavior at position sizes anywhere close to what mainnet users would actually post. Trustless Bitcoin Vaults (TBV) testnet exists specifically to validate the Design before real capital moves through it that Validation is only as good as the position sizes actually getting tested.$BABY
Not saying a capped Faucet is a design flaw Uncapped faucets get drained or Abused and most testnets cap for exactly that reason.
Not saying the cap does Not matter either If every tester works with the same small Allotment certain failure modes cascading liquidations P00l depth issues health factor edge cases at larger positions simply do not get exercised before mainnet.@BabylonLabs_io
What I have not worked out is whether the low claim limit reflects a genuine Security precaution against faucet abuse or whether its quietly limiting How much real Stress Testing the Testnet phase can actually produce before mainnet capital is at stake.
$AKE
$BANK #ShareYourThinking
#baby A faucet that hands out a fixed Small amount per wallet is fine for confirming deposit to borrow mechanics function. Its not fine for stress Testing what happens to Health factor calculations Liquidation Triggers or Aave v4 pool behavior at position sizes anywhere close to what mainnet users would actually post. Trustless Bitcoin Vaults (TBV) testnet exists specifically to validate the Design before real capital moves through it that Validation is only as good as the position sizes actually getting tested.$BABY
Not saying a capped Faucet is a design flaw Uncapped faucets get drained or Abused and most testnets cap for exactly that reason.
Not saying the cap does Not matter either If every tester works with the same small Allotment certain failure modes cascading liquidations P00l depth issues health factor edge cases at larger positions simply do not get exercised before mainnet.@BabylonLabs_io
What I have not worked out is whether the low claim limit reflects a genuine Security precaution against faucet abuse or whether its quietly limiting How much real Stress Testing the Testnet phase can actually produce before mainnet capital is at stake.
$AKE
$BANK #ShareYourThinking
තවත් අන්තර්ගතයන් ගවේෂණය කිරීමට ඇතුල් වන්න