Hello,

I do not expect you accept that PR. It provides a few examples to continue the talk. Maybe that would be better to coordinate on the starkware discord. I could not DM you. Anyway, long story short, a few proposal:

1. SNValToBN is actually almost the same as (i *big.Int{}).SetString(z, 0). The 0 for 2nd parameter checks for 0x and does a .SetString(z, 16) if it has one: If it does not... It works. I've added the change and a test to show it.
2. There is a concern with not checking the value is correct with SNValToBN. If it is in the test or to interact with some backend it is probably okay (though as an oddity keys in pathfinder starknet_getEvents is actually an hexa without 0x in 0.2.2-alpha). However if you expose the conversion in an API, if could lead to the value being nil and the API panicking, i.e. a DDoS.
3. You can probably remove all the HexToBN and StrToBig and replace them with SNValToBN. That would remove utilities and simplify the godoc.
4. Another proposal is simply to not expose SNValToBN by renaming it snValToBN. It would only require a few changes since, except for the example, there is almost no conversion
5. I also propose to remove the replace of the go.mod in your example with the go workspace clause because you already have set the environment to 1.18.

see #174 . This PR:

• adds a v0.2.1 RPC implementation. Noone is using it
• does some cleaning of v0.1.0 RPC and remove the contracts from the directory
• adds a Github Action with devnet 0.3.5 to test the new implementation
• changes the version format from an uint64 to a *big.Int to support format used to run EstimateFee

I'm observing that local starknet tests fail. Is it possible there are additional setup instructions needed in the README?

=== RUN   TestLocalStarkNet
    starknet_test.go:86: Could not deploy contract: 403: unknown_error_format
    starknet_test.go:91: Could not get tx: 403: unknown_error_format
    starknet_test.go:96: Could not get tx receipt: 403: unknown_error_format
    starknet_test.go:101: Could not get block by hash: 403: unknown_error_format
    starknet_test.go:106: Could not get storage: 403: unknown_error_format
--- FAIL: TestLocalStarkNet (1.55s)

Hello, everyone. I am building a TypedData in order to call GetMessageHash and generate a hash based on this data and an account address.

However, the field ChainId in Domain is an int:

type Domain struct {
	Name    string
	Version string
	ChainId int
}

Shouldn't it be *big.Int?

The reason is that the currently Starknet/Starkware values for the Mainnet/Testnet are as follows:

• Testnet (SN_GOERLI): 1536727068981429685321 or 0x534e5f474f45524c49
• Mainnet (SN_MAIN): 23448594291968334 or 0x534e5f4d41494e

These values overflow an int. Testnet and Mainnet are 71 bits and 55 bits long respectively. How can I build a well-formed TypedData.Domain with the proper values for ChainId ?

I'm using Uint256 for ERC721 with Starknet and there is no direct support for that type in caigo. I do not know if that is something I should/could add, considering I'm also an adept of less is better. Uint256 is actually defined in the abi, maybe having an abigen as referenced in #1 would work better.

In the meantime, I am using SplitFactStr to convert the Uint256 into 2 Felt. I would like for the function to work even when the strings are shorter than 32-bytes. I've written a PR with the test that with the current code and succeed with the change. Can you review the PR and provide some feedback?

Thank you for the project!

I attempted to submit a transaction in the following two scenarios:

1. Fee added to execute payload but not enough balance -> Resulted in WaitForTransaction never-ending
2. No fee added to execute payload -> Resulted in WaitForTransaction never-ending

I was only able to figure out this was the issue as Starkscan shows when a TX is rejected due to no fee https://testnet.starkscan.co/tx/0x0018390ddc369f8c5bf66d94aa665df38e750f9b44c394e27e10a4a02e917715#overview

Voyager doesn't present this information.

If Starkscan is able to programmatically catch this scenario, then I'm sure there must be modifications we can make to Caigo to do the same.

Following the upgrade of the StarkNet testnets today, the Goerli2 network has a new chain ID SN_GOERLI2. This pull request allows caigo clients to connect to accounts deployed on Goerli2.

Prior to the StarkNet upgrade a caigo client could connect to Goerli2 as follows:

 gw := gateway.NewProvider(gateway.WithBaseURL("https://alpha4-2.starknet.io"))
 account, err := caigo.NewGatewayAccount(<account private key>, <account address>, gw, caigo.AccountVersion1)

But since the upgrade the returned account has all transactions rejected with the message “Signature (…, …), is invalid, with respect to the public key …, and the message hash …”.

With this pull request clients can successfully connect as follows:

 gw := gateway.NewProvider(gateway.WithChain("SN_GOERLI2"))
 account, err := caigo.NewGatewayAccount(<account private key>, <account address>, gw, caigo.AccountVersion1)

Passing any string which contains "goerli2" in either upper or lower case as the chain ID will work.

Hi folks! Thanks for the SDK, we're using it at Chainlink.

During our analysis we found an issue with the EC Multiplication algorithm.

Caigo’s PrivateToPoint function will multiply the curve generator by the private key scalar, obtaining the public key point. This function is not-constant time and could enable an attacker with knowledge about the timing of key generation to recover the private key. This information leakage will also be present in other side channels such as electromagnetic emanations or CPU temperature. Figure shows a plot of how long the PrivateToPoint function takes depending on the number of set bits on the private scalar:

Exploit Scenario

An attacker gets access to a side-channel on the computer running the GenerateKey function and obtains enough information to recover the private key.

Recommendation

Use a constant time algorithm for scalar multiplication exposed via the PrivateToPoint function. Fix the upper bound on the private scalar sampling.

This is a high difficulty exploit scenario, but we'd still love to patch this before moving to production.

This PR implements the Double-And-Always-Add algorithm which should bring ~10x improvements over the original Double-And-Add implementation, measured as standard deviation when timing the PrivateToPoint function on keys (ec multiplication scalars) with 1 to 251 bits set.

To verify run the the benchmark test where we test multiple different implementations:

$ go test -bench BenchmarkEcMultAll -run=^$
....
-----------------------------
algo=       Double-And-Add
stats(ns)
  mean=     1.0868900971390551e+06
  variance= 1.9250450004438724e+11
  std-dev=  438753.34761616035

-----------------------------
algo=       Double-And-Always-Add
stats(ns)
  mean=     1.595599511976048e+06
  variance= 2.1961769142645793e+09
  std-dev=  46863.385646628  // ~10x IMPROVEMENT

-----------------------------
algo=       Montgomery-Ladder
stats(ns)
  mean=     1.469757121756487e+06
  variance= 2.8182458667915974e+10
  std-dev=  167876.31955673787 // ~2,5x IMPROVEMENT

-----------------------------
algo=       Montgomery-Ladder-Lsh
stats(ns)
  mean=     1.4823170239520958e+06
  variance= 2.667844449605206e+10
  std-dev=  163335.37429489076 // ~2,5x IMPROVEMENT

This PR also brings the fuzz test and adds one signature verification test found in original implementaiton by Starkware here: starkware-libs/crypto-cpp

Resources:

• Wiki | Double And Add
• Wiki | Montgomery Ladder
• Enhanced Elliptic Curve Scalar Multiplication Secure Against Side Channel Attacks and Safe Errors
• Elliptic Curves and Side-Channel Analysis
• Elliptic-curve cryptography VIII - Constant-time scalar multiplication

This PR is a refactor. In includes the following changes:

• Accounts are now shared between the Gateway and RPC implementations. They have been moved up into the caigo directory.
• Plugin support has been added to the session key and both implementation
• Types when shared like FunctionCall have been moved up into the caigo/types directory.
• Implementation specific inner types have been introduced with MarshalJSON/UnmarshalJSON. They are supposed to implement specificities from the API like the fact calldata should be base10 on the gateway
• rpc/types directory has been removed as it should not be used by any higher level package.
• rpc has been renamed rpcv01 has the type system will have to be rewritten and we want to prepare for the yet to come rpcv02
• accounts proposes to install and demonstrate the session key with a v0 account.
• accounts proposes to install v1 and v0 accounts and demonstrates the addInvokeTransaction (i.e. account.Execute`) with the 2 protocol versions
• test provides now facilities for the devnet as requested by https://github.com/dontpanicdao/caigo/issues/135

The Shardlabs devnet allows for minting to an address using the local faucet -> https://github.com/Shard-Labs/starknet-devnet#mint-token---local-faucet

This is necessary when the deployed and funded accounts are not sufficient (e.g. wrong account contract).

It would be great to start adding support for devnet-specific functionality such as this.

Not sure if Caigo maintainers here but the example given in Caigo for balanceOf ignores the 'high' result for Uint256. See https://github.com/dontpanicdao/caigo/tree/main/examples/deploy This is not a good idea as the high field could have a value. In JS, Immutable X does it like this https://github.com/immutable/imx-cairo/blob/main/tests/utils/starknetUtils.ts#L31

I'll look into making a PR if I have a capacity.

👋 I'm David from ImmutableX, while we are planning to support StarkNet for ImmutableX's multi-rollup Orderbook, we noticed that off-chain signing & verification is a hard dependency. Although these features are already supported in other languages like JS & Cairo I see that Caigo seems to only support the basic Account.Sign() as of now.

Do you have any plans to support this in the near future? This seems to be a need for many other projects as well since this is a frequently used functionality.

Also, does anyone know any case or example/implementation of signTypedData or signMessage in Golang?

I tried using v0.1 but starknet-devnet only implements v0.2. The biggest difference seems to be starknet_getNonce and a couple other methods now also take an additional block_id parameter.

https://github.com/starkware-libs/starknet-specs/compare/v0.1.0...v0.2.1

a quick and dirty example of how we can improve the curve apis. with this approach the curve is initialized a single time and helpers are all plain functions.

I am handling over that PR that @internnos has written. Thank to him! I will detail the content of what I am changing here. It seems we are stuck on a test but since there is also an issue with Pathfinder 0.3.0-alpha breaking the interface it might also come from there. Below are the list of my findings:

There are a LOT of breaking changes. btw, @drspacemn I would not go for 1.0 before the protocol ossifies. Right now we have seen they continue to introduce breaking changes in the payload and also it the api. For instance Pathfinder has removed get_code.

• Transaction is used to get data in and out. We used to rely on that fact to enter the entrypoint as a string (i.e. the name of the function) and return in the same data the keccak256 & (252-1) of the function. We cannot do that anymore. What I have done is turn it into a Felt we will have to inject the entrypoint. The reason I did that it that I understand the entrypoint will be removed when calling an account because it will call both __execute__ and __validate__ and whatever the name of the function will be to handle the commit to pay.
• BlockNumber where not consistent accross the stack. I moved them to uint64, not that I am proud of it but at least to have something consistent
• Thinking about it: (1) the curve implementation should be with the Felt implementation and (2) the account should not have a private field but a signer attached to it because it could very well be that the signer authentication does rely on a key that has a different scheme than secp256k1. For now I will leave it that way

Objectives

The JSON RPC API is well implemented. However, not all the routes have their dedicated tests. Make sure we implement those tests with a mock to ease the test process.

Acceptance criteria

• [ ] every API call from the rpc directory should be implemented with a mock

Additional Notes

#78 should be addressed first to make sure we correctly capture the payload