I'm kind of a starter here in the blockchain ecosystem, and I have some questions, but one really seems to bother me since is kind of contradictory.
When you generate a block, each block contains the Header, that contains the previous hash, and hash representation of the current block data, and some other things.
But if every block references the previous block with the hash that was generated with the current data of that block, and every block is immutable...
How can every block in a blockchain can have every other block data if the block is immutable, and also if you change the data, the identity hash of the block immediately changes?
And another one...
Which is the detailed process that happens when there is a transaction available, and how does it incorporates to the blockchain?
Maybe this questions seems kind of dumb to some, but I've been searching and no articles or videos have solved my doubts.
Thanks to all, and have a nice day :)
Every block on the blockchain does not have every other block's data. Actually you might have confused it with Every node (A node is an instance connected to p2p network of blockchain) on blockchain has all the blocks written to the blockchain so far.
So the statement
Every block in a blockchain can have every other block data.
is not true. A block only has data that was added to it at the time of creation after that no data can be added or removed from it.
Now towards your 2nd question
Which is the detailed process that happens when there is a transaction available, and how does it incorporates to the blockchain?
Lets say A transfers B 1 BTC now first of all in order to submit the transaction you have to be connected to blockchain node or a service that is connected to blockchain (bitcoin blockchain in this case) node.
Normally the wallet apps we use to transfer crypto are connected to blockchain node and post our transactions for us.
Once the transaction is given to a node to process initially it is validated and added to what is called mempool which is essentially a place where all the transactions that are yet to be added in blocks live. Mostly nodes have dedicated some space for mempool. Now nodes pick up transaction from mempool (prioritising the one's with higher fee as they get to keep the fee) and add it in a block. This block is called "candidate block".
Nodes start minning candidate block and if they are lucky enough to mine it first the block is broadcasted to the whole network and everyone adds this block to their chain and start minning next block repeating the same process as above.
The Above process is mainly for bitcoin blockchain but other blockchain all of similar processes.
For beginners instead of going through articles and youtube videos i would recommend studying these books to develop a thorough understanding of underlying architecture. There are mainly two type of blockchain (with in crypto eco system) UTXO Based (old ones mainly Bitcoin and its derivaties LTC Zcash DASH etc) and Account Based (New ones Ethereum BNB etc).
For UTXO Based Blockchain.
https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch01.html.
For Account Based Blockchain.
https://www.amazon.com/Mastering-Ethereum-Building-Smart-Contracts/dp/1491971940
Related
So many blockchain documentation tell that the blockchain uses the consensus to verify transactions. But what I understand the consensus only generate the hash to create the new block. I don't know why the documentation says that the consensus verifies the transaction while the transaction has been created (made) before the consensus run for creating the new hash for new block. The consensus flow does not care about the input (group of transactions), it doesn't know the transactions group are valid or not. Why the blockchain documentation say that?
Before getting into details, I'd like to set some context.
First, what is blockchain - blockchain is a set of blocks where every next block depends on a pervious one. And we can extend the chain as long as every new block is correct from system's point of view.
An example of a block chain (starting from a special, genesis, block): A->B->C->D
Every block, other than A, depends on previous one - usually this is based on hashes and some other rules; but a blockchain creator may pick any set of rules.
Second, we need to agree on what is a consensus. In a blockchain world, the consensus is a process to agree on the chain of block. It could be several chains, but the system will get to a consensus on which one is the right one.
Here is why this is important: let's say we have the chain from above with last block being D. In a distributed environment it is totally possible that more than one VALID block will be generated at the same time; and since the system is distributed, several new chains may emerge:
A->B->C->D->E1
A->B->C->D->E2
The consensus in blockchains allows the network as a whole to agree which of this chains is a valid one. Two important properties of a consensus:
it is eventual, it will take a while before every node gets to the same page; which is the same as: if you will ask at the same time different nodes about which chain is the correct one - you may get different answers; but eventually, the network will agree on the same one
there are many different ways how one can pick the right chain, e.g. in bitcoin, the system eventually agrees on a longest valid chain.
Now we can address the original question: "blockchain uses the consensus to verify transactions". Blockchain (distributed one) uses consensus to agree on a chain and it uses a set of rules to validate that every block is correct. Since every node runs a software with the same set of rules, nodes will make same decision on every block correctness. But in distributed blockchain case, more than one chain may emerge...as described above.
To verify transactions blockchain is using set of rules applied locally to either accept or reject new blocks.
The documentation you mentioned does not sound right to me. Here is an example of a doc: https://www.investopedia.com/terms/c/consensus-mechanism-cryptocurrency.asp - I really like their first take away point: "A consensus mechanism refers to any number of methodologies used to achieve agreement, trust, and security across a decentralized computer network." - and, as I mentioned about - it is always worth asking - what is consensus about - in distributed blockchains, the consensus is about the chain itself.
I'm learning about blockchains and one topic I don't quite understand is what happens when you tamper with a block on the chain. What happens to what comes after it?
I get the whole concept of proof-of-work and the hash of both the block itself and the previous one. Mainly, what I don't quite get is once it is proven that a certain block was altered and tampered with due to it no longer connecting to the chain, what happens to the rest that comes after this block?
I know there are two main scenarios that are possible:
The block tampered with is the newest block;
The tampered block is in the middle of the chain;
If it's the newest block, wouldn't the ones that come after it actually approve that information and the data inside the tampered one pass since the hash of the previous block would actually be the one from the tampered? And what if the tampering happened after that block is already on the chain? Would the whole system just cracks and that copy of the blockchain be unconsidered?
Because blockchains work as a system where there's not only one ledger, but several, I get that a block to be added has to pass through a rigorous proof-of-work procedure and if you temper with a block in the middle of the chain, even though you succeeded to mine all following blocks again it still wouldn't work because the several other ledgers will say that this action is not legitimate. Hence, I ask again; where does this block go? Does it just disappear?
Moreover, what stops me from creating a block with fake information, let's suppose that it says I received 5 BTC and I crack the proof-of-work and succeed in finding a nonce that works; how does the system later understand that the information I provided is fake since I'd broadcast to all ledgers that I cracked the nonce and my block is added to the chain?
I'd love it if someone could go over this, it would really help me a lot.
From what I read aggregates must only contain properties which are used to protect their invariants.
I also read sagas can be aggregates which makes sense to me.
Now I modeled a registration process using a saga: on RegistrationStarted event it sends a ReserveEmail command which will trigger an EmailReserved or EmailReservationFailed given if the email is free or not. A listener will then either send a validation link or a message telling an account already exists.
I would like to use data from the RegistrationStarted event in this listener (say the IP and user-agent). How should I do it?
Storing these data in the saga? But they’re not used to protect invariants.
Pushing them through ReserveEmail command and the resulting event? Sounds tedious.
Project the saga to the read model? What about eventual consistency?
Another way?
Rinat Abdullin wrote a good overview of sagas / process managers.
The usual answer is that the saga has copies of the events that it cares about, and uses the information in those events to compute the command messages to send.
List[Command] processManager(List[Event] events)
Pushing them through ReserveEmail command and the resulting event?
Yes, that's the usual approach; we get a list [RegistrationStarted], and we use that to calculate the result [ReserveEmail]. Later on, we'll get [RegistrationStarted, EmailReserved], and we can use that to compute the next set of commands (if any).
Sounds tedious.
The data has to travel between the two capabilities somehow. So you are either copying the data from one message to another, or you are copying a correlation identifier from one message to another and then allowing the consumer to decide how to use the correlation identifier to fetch a copy of the data.
Storing these data in the saga? But they’re not used to protect invariants.
You are typically going to be storing events in the sagas (to keep track of what has happened). That gives you a copy of the data provided in the event. You don't have an invariant to protect because you are just caching a copy of a decision made somewhere else. You won't usually have the process manager running queries to collect additional data.
What about eventual consistency?
By their nature, sagas are always going to be "eventually consistent"; the "state" of an instance of a saga is just cached copies of data controlled elsewhere. The data is probably nanoseconds old by the time the saga sees it, there's no point in pretending that the data is "now".
If I understand correctly I could model my saga as a Registration aggregate storing all the events whose correlation identifier is its own identifier?
Udi Dahan, writing about CQRS:
Here’s the strongest indication I can give you to know that you’re doing CQRS correctly: Your aggregate roots are sagas.
I'm working on IBM MVS (z/OS) and trying to make Window Services working.
On the function CSREVW I don't understand what the purpose of the parameter pfcount.
Acording to the documentation this will ask to the window services to read more than one block after my program references a block that is not in my window.
But how the window services is suposed to know that I tried to reference data that are not in my window? I mean, it can't know that I'm reading data out of my window if i don't call CSREVW or CSRVIEW again.
Maybe my major issue is that I have trouble to understand english but this seems clear to me...
Here is the link to the documentation, this is explained at pages 23-24 :
http://publibz.boulder.ibm.com/epubs/pdf/iea3c102.pdf
I know this is a very specific problem about an IBM service and I apologize about that.
Thank you !
Tim
I think the problem you're having is that you need to understand a little bit about how the underlying objects behind the windowing service work in virtual storage.
At the core, the various windowing services work to give you what amounts to a "private" page dataset. You allocate and reference storage, but the objects in that virtual space aren't really in memory - the system's page fault mechanism brings them in as you reference them. So yes, you're accessing data within a "window", but in reality, the data you expect to see may not be "paged in" at that moment.
Going a little deeper, when you first allocate the object, the virtual storage it's mapped to has all of the pages marked "invalid" in the underlying page table entries. That means that as soon as you touch this storage, a page fault interrupt occurs. At this point, the operating system steps in and resolves the page fault by brining the necessary data into memory, then your program continues, oblivious to all of this processing on your behalf. You're correct that you're just referencing data within the window, but there's a lot under the covers going on to support this.
This is where PFCOUNT comes in...
Let's say you have structures that are, say, 64K long inside your virtual window. It would be sloppy and slow to reference each page of this structure and cause a page fault each time. Much better would be to use PFCOUNT to cause the page you reference and all 15 other pages needed by your object to be paged-in with a single operation. Conversely, if your data was small and you were highly random about how you access it, PFCOUNT isn't going to help you - the next page you reference could be anywhere, and it's actually wasteful to have a large PFCOUNT since you end up bringing in a lot of data you never use.
Hope that makes sense - if you'd like a challenge, take yourself a system dump and examine the system trace entries as you reference data...you'll see a very distinct pattern of page faults, I/O and resumption of your program, and hopefully it will all make sense to you.
From the manual
,pfcount
Specifies the number of additional blocks you want window services to bring into the window each time your program references data that
is not already in the window. The number you specify is added to the
minimum of one block that window services always brings in. That is,
if you specify a value of 20, window services brings in up to 21. The
number of additional blocks ranges from zero through 255.
Note that you get 1 block without asking.
I understand that regmodel values are updated as soon as transaction initiates from test environment on any of the connected interfaces.
However consider a scenario:
RTL registers being updated from ROM on boot-up (different value than default)
Processor in RTL writing to register as compared to test environment.
In these 2 cases regmodel doesn't get updated/mirrored with correct RTL value. I would like to know what is correct procedure to get regmodel updated, if there is none at the moment what other approach can be taken to keep these 2 in sync?
For the first case you have to pre-load your memory model with your ROM contents at the start of the simulation. There isn't any infrastructure to do this in uvm_memory (unfortunately), so you'll have to implement it yourself.
For the second case, you have to use a more grey-box approach to verification. You have to monitor the bus accesses that the processor does to the peripherals and update the register values based on those transactions. This should be OK to do from a maintainability point of view, because the architecture of your SoC should be pretty stable in that sense (you've already decided to use a processor so that will always be there, but you might not know which peripherals will make it to the end).