To put things in context the screenshot is talking about an increase to 1.2MB while the proposal mentions an increase from 600KB to 800KB which is far from 1.2MB
2 Likes
Changes in blockchain contract sizes can potentially break nodes, but the extent to which this happens will depend on a variety of factors, including the design of the blockchain network and the capabilities of the nodes themselves. That is why it is important for the L1 team and maybe validators to advise the community before we vote.
If a blockchain network relies on a large number of nodes to process transactions and validate contracts, then a failure of even a few nodes due to increased contract size could potentially lead to a loss of consensus, causing the blockchain to halt.
On the matter of auditing L2 dApps; does this fall under the purview of Lunc governance?
1 Like
Thatâs not what he is saying here.
What he is saying is that:
-
They have run tests on a Testnet, not a mainnet so we do not know what adverse effects it could have on the mainnet the moment we do the change. It is NOT recommended to do this change. He said that clearly
-
The contract size on the Bombay Testnet is already 1.2 MB which is MORE than the required 800KB. So, someone can run their application over there and test it first before making this change on the mainnet. Let the TerraCasi(no team show us that their app is running on the testnet first
-
Contracts can be split into chunks which are lesser than 600KB is size so it doesnât matter what is the size of the contract. It could be 10MB also but since it can be split into chunks and executed, it will work regardless. This is all you need to tell the developers
-
Right now, increasing contract size increases node operator cost. That is possible when you have AWS servers since they are cloud servers, but it isnât possible to expand a running physical server just like that. TFL has just shifted the node to TR and they have physical servers. They will literally need to run to the market to buy extra RAM modules (which should be supported on the motherboard) if by chance the contract size is too large to execute say, on a 32 GB RAM. A lot of validators might need to do that if the contract size is increased just like that
1 Like
Yeap, got thatâŚ
It was merely an attempt to point out the numbers mentioned in the request in regards to what we already have in the chain so, if possible, become more targeted in our approach to testing/verifying things 
1 Like
If you have a point to make (and itâs not spam) you need to be more specific because all your screenshots (looking at the Age column) are from the pre-depeg period.
1 Like
negative as always
2 Likes
time is passing with so many question and concerns with no answer from the author. this start to smell very fishy. Abstain for now, and Veto if still no answer in a day.
3 Likes
The author explained the reason why he needs the change in the parameter and the only thing others do is be toxic, raise doubts within the community and be an obstacle in the way of those who build.
1 Like
This will remain stuck like this unless they provide us with clear and precise answers to questions we have asked above.
We have also provided alternatives and suggestions so there should no reason to complain.
3 Likes
I don think this is the case. @LuncBurnArmy needs to address the concerns that are expressed on this topic. Itâs not a case that we are against the proposal. We just want to make certain that the chain will not be affected.
2 Likes
Because the way you try to make your point comes out as spam! Calling everyone a scammer doesnât help either.
As I said, if you really have a point to make, pasting screenshots all over the place without explaining what is the point of concern exactly on those screenshots will not give you any answers or get anyoneâs attention. You need to be specific.
Fyi, this is NOT the old LUNA forum any longer but the community-owned LUNA Classic a.k.a LUNC forum.
6 Likes
I donât think many in here follow wLUNA since itâs on the Ethereum chain.
We are all busy trying to revive LUNA Classic a.k.a LUNC as a community-owned chain following the crash last May (2022) when DK abandoned it. Am not even sure if the wLUNA to Luna channel is open for trading tbh, maybe someone else can comment on that last one.
2 Likes
Hi @LuncBurnArmy, have the L1 team looked at this proposal and any possible ramifications as a result? From the prior comment from Jared on increasing the contract size, he mentioned it could increase node operating costs.
We really need some testing and proper analysis to determine what would be the outcome of making this change. Iâm not about to vote YES to changes that have not been tested and where it is not understood what could happen as a result.
Until I receive more information this proposal is going to be a NO for me.
2 Likes
He was in the AMA yesterday and he said that NO ONE from the TerraCasino team has reached out to him and he has not had ANY conversation regarding this till now.
The question isnât whether this can be done or not.
My question rather is, why was there no discussion with the L1 Team before putting this for vote? Whatâs the HURRY?
Also, LBA in the AMA again is saying that he does not âthinkâ that there will be any issue with the change. What does THINK mean exactly @LuncBurnArmy ? You do development work by thinking? Really?
Please do not say such things for which you do not substantial evidence to back up your claims. If you do, then please come here and share test data from unit tests on the code to show what is the exact memory utilisation of the server and what is the exact gas fee difference. And then, you can say that you know what this change does exactly.
Please ask the TerraCasino team to do the same and share the test data with us.
If all your screenshots are about you trying to convert wLUNA to LUNA v1 (or wUST to UST), you may want to give https://www.portalbridge.com a try. It is the portal project of wormhole - you can verify that by either:
-
Terra v1 Documentation:
- https://classic-docs.terra.money/docs/learn/bridges.html
- Look on page for âUse Wormholeâs Portal Token Bridgeâ near bottom of page
-
Older TFL Article verification:
- click this redirect from wormhole (same redirect from the Terra v1 Documentation Above): https://wormholebridge.com/#/transfer
- see that it redirects to portalbridge.com;
- search for the wormhole link outlined in this older article by TFL on wormhole in 2021.
Of course, do you own research, and you can also visit the support forum on this site, and ask them if portalbridge, in their estimation, is appropriate to use currently.
I am not sure if wormhole closed wormhole to Terra v1 via portalbridge.com for wLUNA and wUST (it may only be Terra Classic Shuttle and Terra Classic Bridge that are closed).
I would try with very small amounts (you are using it at your own risk). Your wLUNA is an ETH token, you want to unwrap it to the Terra v1 network (ie. âTerra Classicâ). You can also see this tutorial from the Terra v1 documentation on using portalbridge.com to do the unwrapping from ETH (wLUNA or wUST) to actual LUNA (or UST) on-chain. The only difference is that you want the source network to be ETH and the destination network to be âTerra Classicâ not âTerraâ (since there is now Terra v1 and Terra v2). It is worth a try.
Hope that helps out a little bit.
2 Likes
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
This topic was automatically opened after 44 hours.
Please listen from here (32:47 mins - I have marked the time in the link below):
Zaradar has clearly said here that doing this change is detrim(ental to the system and could result in serious problems.
I had already said this but since you need a confirmation, here it is.
1 Like
Increasing the WebAssembly (WASM) contract size on the Terra Classic blockchain will have several potential effects on validators and gas fees.
-
Increased computational requirements: A larger WASM contract size means more complex and potentially larger smart contracts. This can lead to higher computational requirements for validators, as they need to execute the contracts in the process of validating transactions.
-
Higher storage requirements: With larger contracts, validators will need to allocate more storage space to store the contractâs data on the blockchain. This might result in increased hardware costs for validators and can potentially lead to a smaller number of validators if the cost of participating becomes too high.
-
Longer validation times: As contract complexity and size increase, it can take more time for validators to process transactions. This might lead to longer block times or increased network latency, which can have an impact on the overall performance of the blockchain.
-
Higher gas fees: If contract execution requires more computational power, the cost of processing transactions could increase. This might result in higher gas fees for users who interact with these larger contracts. Additionally, if there are fewer validators due to increased computational and storage requirements, competition for transaction inclusion in blocks can drive gas fees higher.
-
Increased likelihood of bugs: Larger and more complex contracts can potentially introduce more bugs and security vulnerabilities. This can have negative implications for both users and validators, as it might lead to lost funds or compromised network security.
In summary, increasing the WASM contract size on the Terra Classic blockchain can have both positive and negative effects. It might enable more complex and feature-rich applications to be built on the platform, but at the same time, it could impose additional burdens on validators, lead to higher gas fees, and potentially introduce security risks. Itâs essential to carefully evaluate the trade-offs and find the right balance between contract size, performance, and security.
2 Likes