What is the difference between an Account and a Block in Solana Blockchain technology?
As per solana docs,
Block: A contiguous set of entries on the ledger covered by a vote. A leader produces at most one block per slot.
Account: A record in the Solana ledger that either holds data or is an executable program.
From the definitions, it seems like they both are the same which becomes part of the ledger as an individual transaction. Is it like this or something other concept
The word "ledger" is unfortunately overloaded in Solana, since it refers to both transactions and records that hold data. Maybe this will clarify a bit more:
A block is a set of transactions that have been executed (success or failure)
An account is like a file on an operating system. Transactions read / modify accounts based on the behavior of programs / smart contracts
Related
I would like to know if transaction payload in Hyperledger Fabric transaction flow is visible to the ordering nodes.
The goal is to create a private channel, where only the owners of the peers have the possibility to see the payloads and therefore what is saved in the ledger, while we would like to increase the decentralization of the network by distributing the orderer nodes to multiple organization, but it is important that these orderer nodes never know the transaction payload and what is saved on the blockchain.
In my opinion is something possible but I would like to be sure because is a crucial point of the architecture's design.
Orderers do see the data recorded in the ledger by a transaction. If it really isn't practical to have orderers owned by the same set of organisations that own network peers, you might be able to use private data collections:
https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html
Data stored in private collections is shared directly between peers with permission to view that collection, and only a hash of the data is stored in the main ledger and visible to orderers.
I am trying to learn how blockchain works. I know that blockchain is nothing but list of blocks containing transactions, what I cannot understand is how do we then know how much money is contained in each account, since we are only maintaining list of transactions?
In distributed platforms, 2 models of accounting for account balances are most commonly used:
a state model, when each of the nodes, after the execution (or reception) of the transaction, accordingly changes the account state record in its local database (Ethereum, Hyperleger Fabric)
model of unspent remainings (UTXO), when the account balance is formed from the sum of the balances of "unused" transactions (Bitcoin, Corda)
I recently read some where the speaker mentioned bitcoin doesn't store addresses in the block chain. If addresses do not exist on the blockchain, how can you check their balances on - for example - blockchain com?
Payment addresses stored within transactions, and transactions stored within blockchain. Thus, speaker is not right - addresses stored in the blockchain, and by scanning the blockchain, you can fetch all activity for any address. Of course, balance - just result (sum) of all activities.
However, Bitcoin (or other bitcoin-like crypto) does not build it's own address index, and there is impossible quickly fetch balance or activity history for some specific address directly from a node. Explorers scans blockchain and build his own transaction history withing his own database. Of course, when new block comes in, explorer updates his own DB, and by this way - he maintains actual history for all accounts.
I am adding some user data in the blocks of Sawtooth Blockchain. I need to check how much data can be added to a single block.
Is the block size configurable? If yes How can I do it?
I read documentation but not getting any concrete information.
There is no size limit on what can be put in the state store. However, you wouldn't want a big blob be stored on chain. You could however limit maximum batches that can be part of one block.
Block (as in the block created) will reference the list of transactions from the transaction receipts store, and will reference the state root hash from the state store.
I am building decentralized application which grabs data from blockchain to mysql database.
I'm not sure, but I guess it is possible that one part of Ethereum network accepts newly mined transaction X and another part accepts mined transaction Y. Some time later one of this transactions should be accepted by full chain and other transaction should fail.
If my node gets in wrong chain I will have incorrect data on my mysql database. And it will be hard to revert database back.
How to deal correctly with these types of conflicts? Should I grab data only after certain number of confirmations (for example 5 or 10)? Or there is another approach?