Create EOS-Cryptography-Proposal-2.md

[lukapercic]

Project Abstract

We are proposing to add different signature verification algorithms for EOS. There are different ways to achieve this, but doing research and implementation of many libraries on eos-cryptography-proposal lands us on optimizing previous SDK library for smart contracts with addition of custom intrinsics with minimal dependencies (GMP and then quick and cheap migration to BoringSSL once it gets included in the Antelope). This will allow contracts to run without OC (optimized compilation).

For which grant level are you applying?

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $50,000, 3 approvals
• Level 3: Up to $200,000, 4 approvals

Application Checklist

• The application template has been copied, renamed (my_project_name.md) and updated.
• The application file (my_project_name.md) has no spaces in its name, ends with the .md extension has been placed in the applications directory.
• I have read and understood the:
  • FAQs,
  • application guidelines and
  • announcement guidelines.
• An EOS address for the payment of the milestones is provided inside the application.
• I have read and acknowledge the terms and conditions.
• The software delivered for this grant will be released under an open-source license specified in the application.
• This project has NOT been part of a token sale or NFT sale.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted.

How Did You Hear About our grants program?

• Social Media
• EOSNetwork.com
• Personal Recommendation
• ENF Fireside Chat
• Investor/VC
• Online Search
• Hackathon
• Other: _______

[DenisCarriere]

Reviewed & looks good to me 👍

[wanderingbort]

Adding host functions to the protocol carries a very high burden of proof.

In addition to the deliverable above, we would need

1. documented semantics of the in-memory (ABI) representation of the big integers that are passed to/from the functions outlined in fp.hpp. If this representation is different at rest or within the native code, that should be documented as well. (this may or may not be the same as other crypto host functions)
2. documented semantics of all host functions that take references or pointers as input paying careful attention to behavior when boundaries are violated, inputs/outputs are aliased etc. There should be no path for undefined behavior that can result in a consensus affecting bug or poison block
3. IF the implementation of the host functions has any platform specific code paths (for optimization) each platform needs to be noted in this proposal.
4. code coverage for unit tests of the host functions must be 100%
5. As exhaustive testing is infeasible with large numbers, this proposal should include an extensive testing strategy that establishes confidence in the correctness of operations.
6. Given the nature of products built on top of this, the proposal should include attaining and publishing an audit from a well regarded security vendor.
7. This will establish an official "Big Int" for the protocol. This proposal should include how those values are represented in the human-readable output from the RPC and other tools.
8. Following from above, this proposal should add code necessary for serialization and deserialization to the proposed format.

I assume that the above will change the cost structure of the proposal but this is already a level 3 grant so, you should have room to work with.

[edit: removed 7 and 8 as we already have a canonical big integer defined for other crypto host functions]

[smlu]

The addition of the new host function will include most basic modular arithmetic operations such as modadd, modsub, modneg, modmul, moddiv and modinv. These new functions are planned to be added to the existing modexp function in fc:modular_arithmetic.cpp. The host function interface will closely resemble modexp host function, utilizing the span type to represent referenced input/output arguments. Additionally, an integer argument will be introduced to specify the byte order of the inputs, supporting both little-endian and big-endian formats. This approach adds flexibility and can cover different use cases (e.g.: ack bigint has wasm native integer representation, i.e.: little-endian).
For internal implementation of modular arithmetic functions in the node, the GMP library is intended to be utilized, as it is already a part of the code base dependency. Alternatively, if BoringSSL is included in the dependency tree at the time of development, it will be used instead. There will be no platform specific optimization since that is deferred to the underlying library (GMP or BoringSSL).

To ensure comprehensive documentation and quality assurance, all new host functions will be thoroughly documented and accompanied by 100% code coverage tests (thoroughly tested as much as possible, borrowing some of testcases from ack:fp_test and other libraries / test vector references).

[wanderingbort]

The grant evaluator team has had a few internal discussions about this proposal and the downstream load it creates on antelope development.

At this time, we cannot commit to upholding our end of the obligations to review and integrate work done as part of this proposal. Primarily this is because:

• Any change that impacts consensus over the implied state of the chain (as new host functions would) carries an extra burden of scrutiny requiring a best effort to guarantee deterministic operation across all platforms/configurations of the software
  • In this instance, this is made more complicated by the impossible scale of inputs and outputs to the host functions resulting in an inability to exhaustively test behavior
• Any change to consensus requires extensive work with all network participants to deploy upgraded software and activate the new upgrades.
• Antelope development has limited engineering capacity that is already committed to other 3rd party initiatives like Instant Finality and the P2P improvements.

This lack of support would result in delayed milestone acceptance and payment and it is not appropriate for us to create expectations we cannot fulfill. As a result, we are rejecting this proposal.

To mitigate the impact of this rejection, we have a few options:

• With the future release of the leap software we will have an optional mechanism for the block producers of any chain to selectively enable eos-vm-oc on a per contract basis. This is intended for well audited contracts that are core to the operation of the various chains. With this feature it will be possible for select contracts that use the the library version of these primitives and achieve acceptable performance.
• After the release of the leap software that integrates instant finality we can re-evaluate our capacity to accept protocol features via the grant program.

[tedcahalleos]

Per the reasoning of @wanderingbort and the Grant Evaluators, this grant has been rejected. Thank you for your submission and working through this process of the Grant Framework.
Ted Cahall