Thanks for the welcome and glad you find the project interesting, hope my responses answer your questions
I perceive BTFS as a scalable decentralized database solution, wherein files are stored across multiple nodes operated by different users. Due to this architecture, there are minimal concerns about storage limitations. However, in any case, if any concerns about exceeding storage limitations, we can allows extend to integrating additional services such as AR, SWARM, IPFS, or other similar protocols to further enhance our capabilities and method of storing such information.
Yes, data availability relies on the BTFS network. However, the architecture of BTFS has been established for quite some time, and, like any decentralized file protocol, it ensures data availability and retrieval through BTFSās online proof and its robust encryption algorithms. With all this, BTFS provides a strong protocol that prioritizes data accessibility and retrieval. That said, the same could be the same for centralized storage solutions in that operational status depends on a single entityās servers for data availability. This known reason for comparing decentralized and centralised storage makes centralized storage a single point of failure that can also affect data accessibility.
However, the main reason for choosing a decentralized file-sharing protocol over a centralized storage solution is that it aligns with our project values and values of being open source and decentralized for developers to use such information to help in the blockchain space.
When it comes to security considerations, ensure the integrity and immutability of data on the TRON network. Most smart contracts, whether verified or not, generate a bytecode that inherently cannot be mutated or manipulated by bad actors. As I mentioned in one of my previous replies, one approach to maintaining data integrity is by compiling and comparing the bytecode of the stored information in the Solidity database with the bytecode provided by the blockchain on the deployed contract. Any disparities between the two bytecode versions could indicate potential tampering or faulty information, prompting Solide to address such discrepancies accordingly.
Currently, we can tackle such problems and secure our registry smart contracts by restricting the functionality of adding information to the deployer of the contract (provided by an āOwnerableā contract) meaning that only authorized users can add information and currently that only integrated into our Solide IDE. This ensures that no other users can manipulate the data and provides some authenticity in the stored smart contract data using the TRON network.
I do not remember if I greeted you the first time but once again welcome to Season 6, I have read your write up and itās amazing, I want to know if you have any collaborations or partnerships on the line for Solide
Thank you for the warm welcome! Iām delighted that you found the project amazing. Currently, there arenāt any partnerships, but we are exploring the possibility of creating educational content for the Artela network as a collaboration, leveraging Solideās user-friendly IDE designed for their ecosystem. We hope by starting to actively engage in hackathons and creating innovative projects, we aim to showcase the technology we build and bring future collaborations and partnerships.
You are welcome and the pleasure is all of mine, it is a wonderful thing to hear about you planning to partner with Artela on making educational content for their network, so what is the vision for this partnership, what and what topics do you plan to teach in the educational content?
Solide IDE was a project created around the start of the year and Iāve just been adding features. The concepts, ideas and implementation for the Solidity Database and Explorer are all later in the TRON S6 Hackathon, which is the main focus of this hackathon, as it uses TRON and BTTCās BTFS.
For the Artela project, our aim is to expose our work to the community and ensure that what weāre building is genuinely useful for developers. We plan to achieve this by creating comprehensive write-ups and tutorials that seamlessly integrate with an IDE. This means that these contents are both interactive and educational experiences, without needing any download or installation and as a result makes the onboarding and learning as easy as possible for developers.
@SovaSniper please donāt skip my question, that would really be a bad look given that Iāve been doing my research on your project ever since you made your offering public in Season 6 and Iāve been keeping a close watch on comments. I get it how hackathons can be tedious sometimes but you signed up for it.
Hereās an example of another one I experimented with. They are alright to do, just a lot of research. Itās just a simple link that will give you access to the contract source and the educational materials. All are available open-source: Solide
Sorry, I tried to get to all the comments, but I might have missed yours.
The Solidity Database, which is the project for this Hackathon, fills in the gaps of unverified smart contracts. Since currently Solide IDE can load smart contract sources from both verified smart contracts and GitHub, we wanted to provide those without verification more context, benefiting developers in understanding what lies behind the smart contract and its potential implications. Hence, the creation of the Solidity Database as a project catered to smart contracts. We can integrate it into Solide IDE so that if its bytecode exists in the Solidity Database, it can be loaded as if it was verified and we can also store the smart contract source in the database deployed via Solide. In fact, you can try it out by loading a smart contract from a given chain or Github, deploying in Solide IDE and trying to load the newly deployed contract and see if there are some source codes loaded. You can read more from the post, with an example Iāve mentioned: https://solidewidget.azurewebsites.net/address/tron_nile/TE43ModJ1frz3T9uv4bfaARGsTETuPzFnn
Thanks for the update, quite easy to comprehend, I must commend the simplicity of your explanation, given that it will provide unverified smart contracts context, the Solidity Database project seems like a great complement to the Solide ecosystem.
Could you provide more details about how the Solidity Database is integrated with the Solide IDE?
Welcome to Hackathon S6. Can you explain how the Solidity Database can contribute to fostering a future of interoperability across EVM compatible blockchains beyond Tron and bttc networks?
Glad you found my explanation easy to understand. The integration between the Solidity Database and the Solide IDE significantly enhances the development experience for users. When developers use the Solide IDE to deploy a smart contract, the compiled bytecode and corresponding source information are automatically stored in the Solidity Database, ensuring that all smart contracts deployed via Solide have their information securely stored within the Solidity DB (via BTFS and TRON).
With this integration, the Solide IDE gains an additional service of finding the smart contract source code to load on the IDE for developers. Similar to the existing implementation of being able to load from GitHub or verified smart contracts, users can now load verified smart contracts. With the Solidity Database, the IDE can query the Solide DB (deployed on TRON), and if the information exists in the registry, the IDE can retrieve and load the smart contract for the developer, enabling seamless development and exploration of both verified and unverified contracts.
Thanks for replying, once again your explanation left out no details as you made a conscious effort to nail every point. But Iām wondering, do you intend to extend the Solidity Databaseās compatibility to additional blockchain ecosystems in the future, given the success of its integration with TRON? If yes, what aspects of integrating with more chains will you prioritize?
Can you explain more about the process of storing smart contracts on the Solidity Database using BTFS and on-chain with TRON? How does this contribute to transparency and accessibility within the developer community?
No worries, Iāve updated the post to provide further insight into the compatibility with additional blockchain ecosystems so I hope you can give that a read. Essentially, since we store bytecode, it isnāt specific to just one chain. The Solidity Database leverages this capability by utilizing bytecode available on every EVM-based chain to provide smart contract information for users.
In terms of which chains the Solide Project will mainly be focused on are those supported on the Solide IDE.
for the enlightenment I sincerely appreciate.