client signature implemented #20
Conversation
lordshashank
commented
Dec 15, 2024
lordshashank
commented
- Implements signature check for client in smart contract
- adds auth token in config
- adds lighthouse for hosting to work easily in both calibnet and localnet (this ig deprecates the need of buffer service)
- resets the deal trigger to number of files in aggregate for testing purpose, currently set to just 1, can be changed as per need.
| @@ -2,5 +2,6 @@ | |||
| src = 'src' | |||
| out = 'out' | |||
| libs = ['lib'] | |||
| evm_version = 'cancun' | |||
| @@ -0,0 +1,246 @@ | |||
| // SPDX-License-Identifier: MIT | |||
There was a problem hiding this comment.
You should probably link to the place you copied this from
| return result; | ||
| } | ||
|
|
||
| function convertAsciiHexToBytes( |
There was a problem hiding this comment.
Did you figure out what part of the system rejected raw bytes? We are paying a 2x size overhead doing things this way + all of the gas overhead of doing the conversion on chain. Its ok to keep this for now but if we want to move to using this in production its better to fix the software rejecting raw byte labels
| .deserializeDealProposal(amp.message); | ||
| bytes memory encodedData = convertAsciiHexToBytes(proposal.label.data); | ||
| (, address filAddress) = abi.decode(encodedData, (uint256, address)); | ||
| address recovered = recovers( |
There was a problem hiding this comment.
This is very useful code to have for a variety of projects 🙏
| @@ -51,6 +52,15 @@ contract DealClient is AxelarExecutable { | |||
| mapping(bytes => Status) public pieceStatus; | |||
| mapping(bytes => uint256) public providerGasFunds; // Funds set aside for calling oracle by provider | |||
| mapping(uint256 => DestinationChain) public chainIdToDestinationChain; | |||
| event DealNotify( | |||
There was a problem hiding this comment.
Overall I think this change should be in a different contract. "PoRepService" or "BuiltinMarketExtension" or with some better name. The reason is that the original contract is orthogonally useful for use cases of cross chain storage that want to handle any extensions to the deal protocol in some cross chain onramp contract. To be concrete if I want to pay ERC20s for filecoin deal I can
- Do that in the onramp contract cross chain by interacting with a smart contract
- Do that offchain by signing a message that gets validated as you are doing here
One exception is the receiveDataCap handling here which is more of a bug fix for Prover-Axelar contract.
contract-tools/xchain/xchain.go
Outdated
| Size: filabi.PaddedPieceSize(prefixCARSizePadded), | ||
| PieceCID: cid.MustParse(prefixCARCid), | ||
| } | ||
| // prefixPiece := filabi.PieceInfo{ |
There was a problem hiding this comment.
Since this appears not to be necessary I think you should delete this
cc @ribasushi apparently boost doesn't hate us as much as we thought?
contract-tools/xchain/xchain.go
Outdated
| if err != nil { | ||
| log.Fatalf("failed to save aggregate to file: %s", err) | ||
| } | ||
| // send file to lighthouse |
There was a problem hiding this comment.
If you want to land this into the main branch the correct way to do it is to implement a lighthouse buffer, add buffer selection to the config and then use this buffer. The buffer interface is meant to be general enough to handle any sort of thing that can take data store it temporarily and be fetched from by SP (http, IPFS, direct blockchain sync). Let me know if the interface is not good for some reason
| } | ||
| labelString := hex.EncodeToString(encodedLabel) | ||
|
|
||
| dealLabel, err := market.NewLabelFromString(labelString) |
There was a problem hiding this comment.
In the same way I think the changes to the Prover-Axelar contract should be a separate contract I think this functionality should be behind a config option. xchain code here should support both ways of doing deal.
If this integration is too annoying I think we should keep this change in a different branch or in a fork. I don't want the basic prototype flow to be lost with the latest evolution.
