#shareyourthinking
shareyourthinking
156 Aufrufe
2 Kommentare
Hot
Zuletzt
Übersetzung ansehen
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
Anna love BNB:
Third-party dependencies in smart contracts always make me uneasy, one compromised link and the whole thing can fall apart. Always good to hear from devs who think critically about security.
Anmelden und weiter Inhalte entdecken