From f8d873afdccaea60bd24b71ae9fa8ee6e8ee6730 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 12 Oct 2024 13:36:34 +0300 Subject: [PATCH 1/5] Update README.md --- auth/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/auth/README.md b/auth/README.md index 6d3d132d4..79839695c 100644 --- a/auth/README.md +++ b/auth/README.md @@ -18,7 +18,7 @@ Fees serve two purposes for an operator of the network. Fees limit the growth of the state stored by every full node and allow for general purpose censorship of transactions of little economic value. Fees are best suited as an anti-spam mechanism where validators are disinterested in the use of the network and identities of users. -Since Heimdall doesn't support custom contract or code for any transaction, it uses fixed cost transactions. For fixed cost transactions, the validator can top up their accounts on the Ethereum chain and get tokens on Heimdall using the Topup module. +Since Heimdall doesn't support custom contracts or code for any transaction, it uses fixed cost transactions. For fixed cost transactions, the validator can top up their accounts on the Ethereum chain and get tokens on Heimdall using the Topup module. ### Types @@ -26,7 +26,7 @@ Besides accounts (specified in State), the types exposed by the auth module are #### StdSignature -A StdSignature is the types of a byte array. +A StdSignature is the type of a byte array. ``` // StdSignature represents a sig type StdSignature []byte From afdf820742d2fac43365fcb9d15270d33c073c26 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 12 Oct 2024 13:37:41 +0300 Subject: [PATCH 2/5] Update README.md --- bor/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bor/README.md b/bor/README.md index cd8c49567..33a2e25e3 100644 --- a/bor/README.md +++ b/bor/README.md @@ -17,7 +17,7 @@ ## Overview -The validators on bor chain produce blocks in sprints and spans. Hence, it is imperative for the protocol to formalise the validators who will be producers in a range of blocks (`span`). The `bor` module in heimdall facilitates this by pseudo-randomly selecting validators who will producing blocks (producers) from the current validator set. The bor chain fetches and persists this information before the next span begins. `bor` module is a crucial component in heimdall since the PoS chain "liveness" depends on it. +The validators on bor chain produce blocks in sprints and spans. Hence, it is imperative for the protocol to formalise the validators who will be producers in a range of blocks (`span`). The `bor` module in heimdall facilitates this by pseudo-randomly selecting validators who will be producing blocks (producers) from the current validator set. The bor chain fetches and persists this information before the next span begins. `bor` module is a crucial component in heimdall since the PoS chain "liveness" depends on it. ## How does it work @@ -162,4 +162,4 @@ curl localhost:1317/bor/next-span-seed ``` curl "localhost:1317/bor/prepare-next-span?span_id=&start_block=&chain_id=""" -``` \ No newline at end of file +``` From bb9f904e682fd721326f27e094486e03b588fdb2 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 12 Oct 2024 13:42:04 +0300 Subject: [PATCH 3/5] Update README.md --- server/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/server/README.md b/server/README.md index 6a8c208fa..5827e8310 100644 --- a/server/README.md +++ b/server/README.md @@ -6,7 +6,7 @@ The `server` module in Heimdall is responsible for running a REST and gRPC serve ### REST -Every module in heimdall has their own rest endpoints, All of these endpoints are registered in the `server/rest.go` file via `app.ModuleBasics.RegisterRESTRoutes` and it also handle the root endpoints. The `server/rest.go` file also contains the `StartServer` function which starts the REST server. +Every module in heimdall has its own rest endpoints, All of these endpoints are registered in the `server/rest.go` file via `app.ModuleBasics.RegisterRESTRoutes` and it also handle the root endpoints. The `server/rest.go` file also contains the `StartServer` function which starts the REST server. ### gRPC From 2c9d511fdead43c6814d9ce22db518359e06ea60 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Sat, 12 Oct 2024 13:42:57 +0300 Subject: [PATCH 4/5] Update README.md --- staking/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/staking/README.md b/staking/README.md index 1379f407b..41b9246f2 100644 --- a/staking/README.md +++ b/staking/README.md @@ -77,7 +77,7 @@ where * `BlockNumber` is the L1 block number in which the staking transaction was included. * `Nonce` is the count representing all the staking related transactions performed from the new validator's account. This is meant to keep Heimdall and L1 in sync. -Upon broadcasting the message, it goes through `HandleMsgValidatorJoin` handler which checks the basic sanity of the transaction (verifying the validator isn't already existing, voting power, etc.). +Upon broadcasting the message, it goes through `HandleMsgValidatorJoin` handler which checks the basic sanity of the transaction (verifying the validator doesn't already existing, voting power, etc.). The `SideHandleMsgValidatorJoin` side-handler in all the existing (honest) validators then ensures the authenticity of staking transaction on L1. It fetches the transaction receipt from L1 contract and validates it with the data provided in the `MsgValidatorJoin` transaction. Upon successful validation, `YES` is voted. From 90594e1c7b31d185b44033bb0460d634c8ea808a Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Wed, 16 Oct 2024 19:08:47 +0300 Subject: [PATCH 5/5] Update README.md --- staking/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/staking/README.md b/staking/README.md index 41b9246f2..b1fc69b77 100644 --- a/staking/README.md +++ b/staking/README.md @@ -77,7 +77,7 @@ where * `BlockNumber` is the L1 block number in which the staking transaction was included. * `Nonce` is the count representing all the staking related transactions performed from the new validator's account. This is meant to keep Heimdall and L1 in sync. -Upon broadcasting the message, it goes through `HandleMsgValidatorJoin` handler which checks the basic sanity of the transaction (verifying the validator doesn't already existing, voting power, etc.). +Upon broadcasting the message, it goes through `HandleMsgValidatorJoin` handler which checks the basic sanity of the transaction (verifying the validator doesn't already exist, voting power, etc.). The `SideHandleMsgValidatorJoin` side-handler in all the existing (honest) validators then ensures the authenticity of staking transaction on L1. It fetches the transaction receipt from L1 contract and validates it with the data provided in the `MsgValidatorJoin` transaction. Upon successful validation, `YES` is voted.