AVM: opcode for ed25519 verify of arbitrary messages.

[jannotti]

Brings ed25519 verify to feature parity with newly added ecdsa opcodes. Allows verification of any message, rather than requiring "program" and hash(code) prefix.

Same sort of testing as ed25519verify

[codecov-commenter]

Codecov Report

Merging #3218 (d25367d) into master (eea0a75) will decrease coverage by 0.01%.
The diff coverage is 82.35%.

@@            Coverage Diff             @@
##           master    #3218      +/-   ##
==========================================
- Coverage   47.43%   47.42%   -0.02%     
==========================================
  Files         369      369              
  Lines       59494    59507      +13     
==========================================
- Hits        28221    28219       -2     
- Misses      27984    28000      +16     
+ Partials     3289     3288       -1     

Impacted Files	Coverage Δ
data/transactions/logic/doc.go	77.41% <ø> (ø)
data/transactions/logic/opcodes.go	100.00% <ø> (ø)
data/transactions/logic/eval.go	85.67% <82.35%> (-0.05%)	⬇️
ledger/blockqueue.go	81.03% <0.00%> (-2.88%)	⬇️
network/wsPeer.go	65.83% <0.00%> (-2.23%)	⬇️
network/requestTracker.go	70.25% <0.00%> (-1.30%)	⬇️
data/abi/abi_type.go	92.03% <0.00%> (-1.00%)	⬇️
network/wsNetwork.go	62.84% <0.00%> (-0.50%)	⬇️
catchup/service.go	69.82% <0.00%> (+0.49%)	⬆️
ledger/acctupdates.go	65.96% <0.00%> (+0.95%)	⬆️
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eea0a75...d25367d. Read the comment docs.

[tsachiherman]

@jannotti could you hold off with this PR until after the batch verification get merged in ? There are some verification semantics that would be better off be uniform.

[jannotti]

@jannotti could you hold off with this PR until after the batch verification get merged in ? There are some verification semantics that would be better off be uniform.

Sure, it's not time critical (belongs in AVM 1.1 and is gated by TEAL 6 in vFuture). But how can batch verification impact this? This is only for signature checking inside of AVM code. As long as there exists a crypto.SignatureVerifier.VerifyBytes type function (for verifying a single signature), this code will be unchanged.

[pzbitskiy]

The code looks good. Not sure about _bare naming, and the use case (remembering ed25519verify has such specific behavior because of avoiding some kind of misuses).

[jannotti]

Now that we have the EnableBatchVerification consensus parameter, would it be reasonable to put this into the upcoming release? The call to func (v SignatureVerifier) VerifyBytes would be supplied the BatchVerify flag. Since it would release along with BatchVerification, there would be no backward compatibility issues.

[ryanRfox]

Please consider an alternate to "bare" which may be more descriptive, such as "bytes" or "data".

[ryanRfox]

@algorandskiy regarding misuse of this opcode, how and where do we inform developers of these risks and proper mitigation? OpCode description and/or Dev Portal docs?

[jasonpaulos]

Code changes look good.

My only suggestion is that it would be nice to add a note in opDocExtras in either/both of the ed25519 opcode descriptions to describe how they differ, but that is not essential.