In our new protocol, the integrity of the data, the order of the columns, and the correct order of the column entries are proven. Additionally, if the EZ side has done the RS encoding process correctly and the $k$ of $n$ column node signatures are aggregated, we can ensure the data is available. However, there is a problem with the design: we cannot be sure that EZ does the RS encoding operation correctly. We may need a super node to check this. When we examine the Avail design, the fact that column nodes verify the columns does not guarantee that the data is available. For this reason, there is a super node definition in that design, and they explained it as follows: "For classical ones (full node), it takes the entire matrix 𝐷, extends each column to 2𝑛 points and getting an extended matrix 𝐷′. It then verifies for each row of 𝐷′".

While we encode our data, we make a row-wise expansion. This is because we can be sure that the data can be created when we receive enough verification instead of waiting for a response from all nodes. We can do a column-wise expansion like Avail does, but in this case, we will need to get a verification response from all nodes. As a different application, we add a new node definition, namely row nodes and firstly, row nodes check whether the RS process is done correctly or not, and then column nodes may also be responsible for data availability. Or column nodes can check the commitment of 1 row and 1 column at the same time. In this case, the structure is a little closer to the Ethereum design. We need to think about this in detail.