Initialize katana grpc api #2682
Conversation
WalkthroughOhayo! This pull request introduces significant updates to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 bufcrates/katana/grpc/proto/starknet.protoConfig file JSON parsing error: invalid character 'v' looking for beginning of value. Please check your buf configuration file for JSON syntax errors. crates/katana/grpc/proto/types.protoConfig file JSON parsing error: invalid character 'v' looking for beginning of value. Please check your buf configuration file for JSON syntax errors. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (12)
crates/katana/grpc/build.rs (3)
1-3: Ohayo! Consider using a more specific error type.While using
Box<dyn std::error::Error>works, we could make the error handling more explicit for build scripts.-fn main() -> Result<(), Box<dyn std::error::Error>> { +fn main() -> std::io::Result<()> {
4-8: Enhance error messages for environment variables.The current error messages could be more descriptive to help developers understand what went wrong during the build process.
- let out_dir = - PathBuf::from(std::env::var("OUT_DIR").expect("OUT_DIR environment variable not set")); - let target = std::env::var("TARGET").expect("TARGET environment variable not set"); + let out_dir = PathBuf::from( + std::env::var("OUT_DIR").expect("OUT_DIR not set. This should be set by cargo build"), + ); + let target = std::env::var("TARGET") + .expect("TARGET not set. This should be automatically set by cargo build");
16-16: Consider more specific rebuild triggers.While watching the entire proto directory is valid, you might want to be more specific about which files trigger rebuilds.
- println!("cargo:rerun-if-changed=proto"); + println!("cargo:rerun-if-changed=proto/starknet.proto"); + println!("cargo:rerun-if-changed=proto/common.proto");Cargo.toml (1)
Line range hint
246-252: Ohayo! Some architectural guidance for the gRPC implementation, sensei!Since you're initializing a new gRPC API, consider these points:
- Align with existing gRPC patterns in the
torii-grpccrate- Utilize the existing gRPC dependencies (
tonic,prost, etc.) consistently- Consider implementing reflection service using
tonic-reflectionfor better API discoverability- Plan for both sync and async clients (note the presence of
tonic-web-wasm-client)crates/katana/grpc/proto/starknet.proto (3)
79-80: Suggestion: Usegoogle.protobuf.Emptyfor Empty Request MessagesOhayo sensei! To simplify the code and adhere to best practices, consider using
google.protobuf.Emptyinstead of defining empty messages likeSpecVersionRequest.You can modify the code as follows:
Import the Empty proto:
+import "google/protobuf/empty.proto";Update the
SpecVersionRPC method:-rpc SpecVersion(SpecVersionRequest) returns (SpecVersionResponse); +rpc SpecVersion(google.protobuf.Empty) returns (SpecVersionResponse);Remove the
SpecVersionRequestmessage:-message SpecVersionRequest {}This approach reduces redundancy and leverages standard protobuf definitions.
207-211: Clarify Simulation Flags FieldOhayo sensei! The
simulation_flagsfield inEstimateFeeRequestis defined asrepeated string. To enhance clarity and prevent invalid flag values, consider using anenumor a predefined set of constants.For example, define an
enumfor simulation flags:enum SimulationFlag { SIMULATION_FLAG_UNSPECIFIED = 0; SIMULATION_FLAG_SKIP_VALIDATE = 1; SIMULATION_FLAG_SKIP_FEE_CHARGE = 2; // Add more flags as needed }Then update the request message:
message EstimateFeeRequest { repeated types.Transaction transactions = 1; - repeated string simulation_flags = 2; + repeated SimulationFlag simulation_flags = 2; types.BlockID block_id = 3; }This ensures only valid flags are used and helps with type checking.
118-121: Parameter Order Consistency inGetStorageAtRequestOhayo sensei! For consistency and clarity, consider placing
contract_addressbeforeblock_idinGetStorageAtRequest, as the contract address is the primary focus of the request.Here's the adjusted message:
message GetStorageAtRequest { + types.Felt contract_address = 1; + types.Felt key = 2; + types.BlockID block_id = 3; - types.BlockID block_id = 1; - types.Felt contract_address = 2; - types.Felt key = 3; }This order aligns with other requests where the primary identifier comes first.
crates/katana/grpc/proto/types.proto (5)
108-121: Ohayo sensei! Potential inconsistency in field namingIn
DeployAccountTxnV3(lines 108-121), the fieldcontract_address_salt(line 113) is consistent withDeployAccountTxnbut consider ensuring that all similar fields across transaction messages use consistent naming conventions. This aids in readability and maintainability of the codebase.
278-290: Ohayo sensei! Inconsistent field naming inExecutionResourcesIn the
ExecutionResourcesmessage (lines 278-290), most fields are named with the suffix_builtin_applications, except forsegment_arena_builtin(line 288). For consistency, consider renamingsegment_arena_builtintosegment_arena_builtin_applications.Apply this diff to rename the field:
message ExecutionResources { // ... - uint64 segment_arena_builtin = 10; + uint64 segment_arena_builtin_applications = 10; }
123-127: Ohayo sensei! Review JSON field names for consistencyIn
ResourceBoundsMapping(lines 123-127), thejson_nameof fieldsl1_gasandl2_gasare set as"L1_GAS"and"L2_GAS"(lines 124-125) in uppercase. Elsewhere in the file, JSON names use snake_case. For consistency and to follow standard JSON naming conventions, consider updating them to lowercase with underscores.Apply this diff to update the
json_name:message ResourceBoundsMapping { - ResourceBounds l1_gas = 1 [json_name = "L1_GAS"]; - ResourceBounds l2_gas = 2 [json_name = "L2_GAS"]; + ResourceBounds l1_gas = 1 [json_name = "l1_gas"]; + ResourceBounds l2_gas = 2 [json_name = "l2_gas"]; }
317-322: Ohayo sensei! Enhance flexibility ofEventFilterfieldsIn the
EventFiltermessage (lines 317-322), all fields are required by default. To allow for more flexible event filtering, consider marking fields as optional by using wrappers (e.g.,google.protobuf.StringValue) oroneofconstructs. This way, clients can specify only the filters they need.
226-237: Ohayo sensei! Clarify field naming inBlockHeaderIn
BlockHeader(lines 226-237), the fieldl1_da_mode(line 235) might be unclear to some readers. For improved clarity, consider renaming it tol1_data_availability_modeto match the naming convention used elsewhere.Apply this diff to rename the field:
message BlockHeader { // ... - string l1_da_mode = 9; + string l1_data_availability_mode = 9; }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (6)
Cargo.toml(2 hunks)crates/katana/grpc/Cargo.toml(1 hunks)crates/katana/grpc/build.rs(1 hunks)crates/katana/grpc/proto/starknet.proto(1 hunks)crates/katana/grpc/proto/types.proto(1 hunks)crates/katana/grpc/src/lib.rs(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- crates/katana/grpc/Cargo.toml
- crates/katana/grpc/src/lib.rs
🔇 Additional comments (5)
crates/katana/grpc/build.rs (2)
18-19: LGTM! Clean error propagation.
The error handling here is appropriately simple for a build script, using the ? operator to propagate errors up the chain.
10-14: Verify the proto file path exists.
The hardcoded path to the proto file should be verified to ensure it exists in the expected location.
✅ Verification successful
ohayo sensei,
Proto file path exists at the expected location relative to build.rs.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the proto file exists and verify its content
# Check if the proto file exists
if [ -f "proto/starknet.proto" ]; then
echo "Proto file exists"
# Show the service definitions
grep -A 5 "service" proto/starknet.proto
else
echo "Error: proto/starknet.proto not found"
# List available proto files
find . -name "*.proto"
fi
Length of output: 339
Cargo.toml (2)
184-184: Verify dependency optimization impact, sensei!
The optimization of num-traits by disabling default features is good for reducing unnecessary dependencies. However, let's ensure this change doesn't affect existing functionality.
Let's check the usage:
#!/bin/bash
# Description: Check num-traits usage across the codebase
# Find all uses of num-traits
rg --type rust "use.*num_traits"
# Find any potential trait implementations
rg --type rust "impl.*num_traits" 22-22: Ohayo! New workspace member looks good, sensei!
The addition of crates/katana/grpc is well-structured and aligns perfectly with the PR objective to initialize the Starknet gRPC API.
Let's verify the crate structure:
✅ Verification successful
Ohayo! There was an issue with the previous verification script. Let's try again, sensei!
Ohayo! Everything looks good, sensei!
The crates/katana/grpc directory exists and contains the essential files as expected.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the new crate structure and its basic files
# Check if the crate directory exists and has the expected structure
fd --type d "^grpc$" crates/katana
# Check for essential files
fd --type f "^(Cargo.toml|build.rs|lib.rs)$" crates/katana/grpc
Length of output: 1428
Script:
#!/bin/bash
# Description: Verify the new crate structure and its basic files
# Check if the grpc directory exists
fd --type d "^grpc$" crates/katana
# Check for essential files
fd --type f "^(Cargo.toml|build.rs|lib.rs)$" crates/katana/grpc
Length of output: 210
crates/katana/grpc/proto/starknet.proto (1)
222-223: Consistent Use of google.protobuf.Empty
Ohayo sensei! Following the earlier suggestion, you can replace BlockNumberRequest with google.protobuf.Empty to maintain consistency and simplify the code.
| message GetTransactionStatusResponse { | ||
| string finality_status = 1; | ||
| string execution_status = 2; | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use Enums Instead of Strings for Status Fields
Ohayo sensei! To enhance type safety and prevent invalid status values, consider using enum types for finality_status and execution_status instead of plain string.
Here's how you can define the enums:
enum FinalityStatus {
FINALITY_STATUS_UNSPECIFIED = 0;
FINALITY_STATUS_PENDING = 1;
FINALITY_STATUS_ACCEPTED_ON_L2 = 2;
FINALITY_STATUS_ACCEPTED_ON_L1 = 3;
FINALITY_STATUS_REJECTED = 4;
}
enum ExecutionStatus {
EXECUTION_STATUS_UNSPECIFIED = 0;
EXECUTION_STATUS_NOT_RECEIVED = 1;
EXECUTION_STATUS_RECEIVED = 2;
EXECUTION_STATUS_PENDING = 3;
EXECUTION_STATUS_ACCEPTED = 4;
EXECUTION_STATUS_REJECTED = 5;
}Then update the message:
message GetTransactionStatusResponse {
- string finality_status = 1;
- string execution_status = 2;
+ FinalityStatus finality_status = 1;
+ ExecutionStatus execution_status = 2;
}This change ensures that only valid status values are used and helps with code maintenance.
| message SyncingResponse { | ||
| oneof result { | ||
| bool not_syncing = 1; | ||
| types.SyncStatus status = 2; | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Clarify the SyncingResponse Structure
Ohayo sensei! The current SyncingResponse uses a oneof to return either a boolean or a SyncStatus. To improve clarity, consider defining a single response that always includes the syncing status.
Here's a possible revision:
message SyncingResponse {
bool is_syncing = 1;
types.SyncStatus status = 2;
}In this structure:
- When
is_syncingisfalse, thestatusfield can be omitted. - When
is_syncingistrue, thestatusfield provides detailed sync information.
This approach simplifies client-side handling of the response.
| message Transaction { | ||
| oneof transaction { | ||
| InvokeTxnV1 invoke_v1 = 1; | ||
| InvokeTxnV3 invoke_v3 = 2; | ||
| DeclareTxnV1 declare_v1 = 3; | ||
| DeclareTxnV2 declare_v2 = 4; | ||
| DeclareTxnV3 declare_v3 = 5; | ||
| DeployAccountTxn deploy_account = 6; | ||
| DeployAccountTxnV3 deploy_account_v3 = 7; | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Ohayo sensei! Reduce duplication by extracting common transaction fields
The transaction messages within the Transaction oneof (lines 24-32) share several common fields like type, version, signature, and nonce. Consider creating a CommonTransactionFields message to encapsulate these fields, reducing duplication and enhancing maintainability.
Here's how you might define a common message and use composition:
message CommonTransactionFields {
string type = 1 [json_name = "type"];
string version = 2 [json_name = "version"];
repeated Felt signature = 3 [json_name = "signature"];
Felt nonce = 4 [json_name = "nonce"];
}
message InvokeTxnV1 {
CommonTransactionFields common = 1;
Felt max_fee = 2 [json_name = "max_fee"];
Felt sender_address = 3 [json_name = "sender_address"];
repeated Felt calldata = 4 [json_name = "calldata"];
}
// Update other transaction messages similarly| message DeclareTxnV2 { | ||
| string type = 1 [json_name = "type"]; | ||
| Felt sender_address = 2 [json_name = "sender_address"]; | ||
| Felt compiled_class_hash = 3 [json_name = "compiled_class_hash"]; | ||
| Felt max_fee = 4 [json_name = "max_fee"]; | ||
| string version = 5 [json_name = "version"]; | ||
| repeated Felt signature = 6 [json_name = "signature"]; | ||
| Felt nonce = 7 [json_name = "nonce"]; | ||
| bytes class = 8 [json_name = "contract_class"]; | ||
| } |
There was a problem hiding this comment.
Ohayo sensei! Consider renaming the class field to avoid reserved keyword conflicts
In the DeclareTxnV2 message (lines 70-79), the field named class (line 78) may cause issues during code generation in languages where class is a reserved keyword (e.g., Python, Java, C++). To enhance cross-language compatibility, it's advisable to rename this field to something like contract_class.
Apply this diff to rename the field:
message DeclareTxnV2 {
// ...
- bytes class = 8 [json_name = "contract_class"];
+ bytes contract_class = 8 [json_name = "contract_class"];
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| message DeclareTxnV2 { | |
| string type = 1 [json_name = "type"]; | |
| Felt sender_address = 2 [json_name = "sender_address"]; | |
| Felt compiled_class_hash = 3 [json_name = "compiled_class_hash"]; | |
| Felt max_fee = 4 [json_name = "max_fee"]; | |
| string version = 5 [json_name = "version"]; | |
| repeated Felt signature = 6 [json_name = "signature"]; | |
| Felt nonce = 7 [json_name = "nonce"]; | |
| bytes class = 8 [json_name = "contract_class"]; | |
| } | |
| message DeclareTxnV2 { | |
| string type = 1 [json_name = "type"]; | |
| Felt sender_address = 2 [json_name = "sender_address"]; | |
| Felt compiled_class_hash = 3 [json_name = "compiled_class_hash"]; | |
| Felt max_fee = 4 [json_name = "max_fee"]; | |
| string version = 5 [json_name = "version"]; | |
| repeated Felt signature = 6 [json_name = "signature"]; | |
| Felt nonce = 7 [json_name = "nonce"]; | |
| bytes contract_class = 8 [json_name = "contract_class"]; | |
| } |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2682 +/- ##
==========================================
+ Coverage 57.57% 57.58% +0.01%
==========================================
Files 404 404
Lines 51139 51139
==========================================
+ Hits 29441 29447 +6
+ Misses 21698 21692 -6 ☔ View full report in Codecov by Sentry. |
tarrencev
force-pushed
the
initkatanagrpc
branch
from
3e33e97 to
2376fc6
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (7)
crates/katana/grpc/Cargo.toml (3)
1-7: Add package description fieldOhayo! The package configuration looks clean, but adding a description field would help other developers understand this package's role in the Katana ecosystem.
[package] edition.workspace = true license-file.workspace = true name = "katana-grpc" +description = "gRPC API implementation for Katana, providing Starknet API compatibility" repository.workspace = true version.workspace = true
11-12: Add testing utilities for gRPC developmentFor proper testing of our gRPC services, we should include these testing utilities:
[dev-dependencies] +tokio-test = { workspace = true } +tonic-build = { workspace = true }
1-15: Consider API versioning strategyOhayo sensei! Since this is initializing a new gRPC API for Starknet compatibility, we should consider:
- Adding version prefixes to service definitions
- Implementing backward compatibility measures
- Documenting breaking changes policy
This will help maintain API stability as the Dojo stack evolves.
crates/katana/grpc/proto/types.proto (4)
17-21: Ohayo sensei! Consider making enum values more explicitThe SimulationFlag enum values implicitly start from 0. For better maintainability and explicit intent, consider assigning values explicitly:
enum SimulationFlag { - SKIP_FEE_CHARGE = 0; - SKIP_EXECUTE = 1; - SKIP_VALIDATE = 2; + SIMULATION_FLAG_UNSPECIFIED = 0; + SKIP_FEE_CHARGE = 1; + SKIP_EXECUTE = 2; + SKIP_VALIDATE = 3; }
142-173: Ohayo sensei! Consider adding documentation for block typesThe different block representations (BlockWithTxHashes, BlockWithTxs, BlockWithReceipts) could benefit from comments explaining their specific use cases and when to use each type.
226-237: Ohayo sensei! Consider adding timestamp validationThe BlockHeader's timestamp field might benefit from validation to ensure it's not in the future and within acceptable bounds.
258-258: Consider structured error handling for revert_reasonThe
revert_reasonfield as a string might benefit from a more structured approach, such as an error code enum with associated messages.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (6)
Cargo.toml(2 hunks)crates/katana/grpc/Cargo.toml(1 hunks)crates/katana/grpc/build.rs(1 hunks)crates/katana/grpc/proto/starknet.proto(1 hunks)crates/katana/grpc/proto/types.proto(1 hunks)crates/katana/grpc/src/lib.rs(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- crates/katana/grpc/proto/starknet.proto
🚧 Files skipped from review as they are similar to previous changes (3)
- Cargo.toml
- crates/katana/grpc/build.rs
- crates/katana/grpc/src/lib.rs
🔇 Additional comments (5)
crates/katana/grpc/Cargo.toml (1)
13-15: Verify workspace-level protobuf build configuration
The build dependencies look good for both native and WASM targets, sensei! Let's verify the workspace configuration:
✅ Verification successful
ohayo, sensei! Workspace-level protobuf build configuration verified.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check workspace-level dependency configuration
rg -A 5 'tonic-build|wasm-tonic-build' Cargo.toml
# Verify proto files existence
fd -e proto . crates/katana/grpc/
Length of output: 564
crates/katana/grpc/proto/types.proto (4)
1-4: Ohayo sensei! The file structure looks good!
The proto3 syntax declaration and package naming follow the Protocol Buffers best practices.
23-121: Previous comment about reducing transaction field duplication is still valid
The transaction messages (InvokeTxnV1, InvokeTxnV3, DeclareTxnV1, etc.) share common fields like type, version, signature, and nonce. Consider extracting these into a common message type.
123-140: Ohayo sensei! Resource and fee structures are well-designed!
The separation of L1/L2 gas and comprehensive fee breakdown provide clear resource management.
78-78: Previous comment about renaming the class field is still valid
The class field should be renamed to avoid conflicts with reserved keywords in various programming languages.
| [dependencies] | ||
| tonic.workspace = true | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider adding essential gRPC-related dependencies
Ohayo sensei! For a robust gRPC implementation, we should consider adding these common dependencies:
[dependencies]
tonic.workspace = true
+prost.workspace = true
+tokio = { workspace = true, features = ["rt-multi-thread", "macros"] }
+tonic-types.workspace = true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [dependencies] | |
| tonic.workspace = true | |
| [dependencies] | |
| tonic.workspace = true | |
| prost.workspace = true | |
| tokio = { workspace = true, features = ["rt-multi-thread", "macros"] } | |
| tonic-types.workspace = true |
|
|
||
| message StateDiff { | ||
| repeated StorageDiff storage_diffs = 1; | ||
| repeated Felt deprecated_declared_classes = 2; |
There was a problem hiding this comment.
💡 Codebase verification
ohayo sensei!
Deprecated deprecated_declared_classes field is still present
- The
deprecated_declared_classesfield remains in multiple files without removal or replacement.
🔗 Analysis chain
Verify the usage of deprecated declared classes
The deprecated_declared_classes field suggests a migration or deprecation process. Let's verify its usage:
ohayo sensei!
The previous search for deprecated_declared_classes didn't work due to an unrecognized file type. Let's try searching without specifying the file type:
ohayo sensei!
Let's gather more details on how deprecated_declared_classes is being used:
ohayo sensei!
Let's gather more details on how deprecated_declared_classes is being handled:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for references to deprecated declared classes
rg -l "deprecated_declared_classes" --type proto
Length of output: 78
Script:
#!/bin/bash
# Search for references to deprecated declared classes in all files
rg -l "deprecated_declared_classes"
Length of output: 308
Script:
#!/bin/bash
# Find all instances and their contexts of 'deprecated_declared_classes' in the listed files
rg "deprecated_declared_classes" crates/saya/provider/src/rpc/state.rs crates/saya/core/src/prover/program_input.rs crates/torii/grpc/src/types/mod.rs crates/torii/grpc/src/client.rs crates/katana/grpc/proto/types.proto crates/katana/primitives/src/state.rs crates/katana/rpc/rpc-types/src/state_update.rs
Length of output: 1978
Script:
#!/bin/bash
# Search for comments and functions related to 'deprecated_declared_classes'
rg "deprecated_declared_classes" crates/saya/provider/src/rpc/state.rs crates/saya/core/src/prover/program_input.rs crates/torii/grpc/src/types/mod.rs crates/torii/grpc/src/client.rs crates/katana/grpc/proto/types.proto crates/katana/primitives/src/state.rs crates/katana/rpc/rpc-types/src/state_update.rs
Length of output: 1978
|
we still want to maintain jsonrpc (mainly for compatibility reason) so we should expose both protocols, with jsonrpc being the default option. something like |
There was a problem hiding this comment.
@tarrencev did you generate this from the spec? Or it's handmade? If auto-generated, would be great to have the script somewhere to follow upcoming RPC upgrades of the network. 👍
We should also have some protos defined globally in a crate for the dojo stack since torii an other part of the stack will share those types to base the implementation on it.
We could do that in a second time though.
good point, lets focus on getting it implemented on katana, torii, and sozo. in that particular order. |
Most of these are protos we're using internally for the paymaster. It is a combination of hand rolled and gpt generated from the spec. I imagine they might further evolve but wanted to get things started |
Initializing a starknet grpc api to Katana for usage with Torii and the rest of the Dojo stack
Summary by CodeRabbit
New Features
Bug Fixes
Documentation