Skip to content

Milestones

List view

  • Milestone 3

    Milestone 3 The focus here would be improving reliability/performance and adding/tweaking features based on feedback from the infra providers that ran the beta application in production. Also we should have comprehensive documentation aimed at infrastructure providers and I'd like to provide examples of deployment and scripts to automate setup. We can decide more details once we get to this stage. Should be considered production ready at this stage.

    No due date
    •0/2 issues closed
    0% complete2 open0 closed

  • Milestone 2

    Milestone 2 This milestone should be able to understand AntelopeIO specific RPC requests and run custom logic depending on the request context. The rpc documentation is here: https://docs.eosnetwork.com/apis/leap/latest/chain.api As an example of custom logic that the firewall should be able to handle. When receiving a request on the get_table_rows endpoint the firewall should be able to implement custom rate limits based on parameters such as scope, table and code request parameters. Additionally, the firewall should be able to implement custom rate limits based on push_transactions and send_transaction endpoints. The firewall should be able to decode the push transaction data and implement custom logic to rate limit based on that. When the firewall proxies the transaction data through to an rpc node the firewall should also be able to read the results of that transaction (generally it will be a success receipt or a failure message). Rate limiting/ blacklisting should also be able to be implemented based on this transaction response context. For example the node might blacklist an IP and/or signing account based on too many failed push transactions. The firewall could also do things like, only accept one transfer action per second per chain account and reject transactions that contain multiple transfer actions bundled together. Likewise the infra provider could whitelist specific contract actions or signing accounts so they are never rate limited or rate limited using different parameters. When the firewall reads push_transaction responses it can track the reported CPU billing cost and use this aggregate CPU cost as part of the rate limiting logic (for example each account gets 100 virtual CPU ms per day which are spent when they submit a failed transaction, preventing accounts from spamming many failed transactions without consequence). I'd like the ability to "hook" into the request flow to be pluggable and flexible so we can add/remove logic in various places without refactoring code. The infrastructure provider should be able to enable/disable/configure everything using the config file and/or an admin rpc endpoint. For deserializing transaction/ rpc data we should be able to pull from some of the libraries out there. I haven't dove into the details but I would look at these first. https://crates.io/crates/substreams-antelope https://github.com/sagan-software/eosio-rust If we have to write rust antelope rpc bindings ourselves, the best to study would be this one in typescript https://github.com/greymass/eosio-core or the c++ source code here: https://github.com/AntelopeIO/leap/blob/main/plugins/chain_api_plugin/chain_api_plugin.cpp Any questions feel free to ask us as we work with this eosio-core library every day. The node should also have some basic stats exposed via an endpoint, can be as simple as a JSON object that contains state data about the firewall.

    No due date
    •0/2 issues closed
    0% complete2 open0 closed

  • Milestone 1

    For milestone 1 the focus will be on basic routing and blacklisting. Implementing blacklisting based on IP and request frequency should be an easy goal for us. I'd also like to prioritize a test suite that allows us to test the latency and resource usage of the firewall in a repeatable way over time so it's easy for us to track down bottlenecks. There will be minimal AntelopeIO specific code in this milestone, just focus on the foundations of request proxying. We should also start thinking about configuration, how does the infra provider configure the firewall, is it just a config file or maybe there is an admin rpc they can push commands to for live updates.

    No due date
    •0/3 issues closed
    0% complete3 open0 closed