Getting completed in half the time is a huge variation off the estimates. To me, that would indicate a significant risk that what your team actually did deviates from what the users expected at the beginning of the Sprint. In addition, a Sprint is also supposed to deliver enough functionality that it's now time for new feedback from the PO.
So the risk in just grabbing stuff off the top of the PB and carrying on is that those items on the top of the PB are out of date (both in content and priority), and that your Team has gotten something wrong in the last Sprint and you'll just be building on those mistakes without getting feedback from the PO.
I'd say that the most reasonable course of action is to call the Sprint done, hold your usual end of Sprint review, planning meeting and retrospective and get started on the next Sprint.
As to the burndown chart stuff, the original question seems to miss the point of the what it's for. It's really just a tool to determine if you're having a problem with the progress during your Sprint. With what was described, the burndown chart should have come into play in this situation on about day 2 or 3 of the Sprint, when it would have shown that the Team was way, way ahead of schedule on the Sprint tasks. Then you ask the question "Why?", and determine if your estimates were just way off or maybe the programmers are mis-interpreting the tasks, or if something is going off the rails in some way.
But when you ignore the burndown chart and cruise on like there's nothing odd going on, then it looks like you're just treating it as some pointless artifact you're producing because the "book" tells you to. In my opinion, if you should decide to just pull some more stuff off the top of the PB and carry on for the second week, then just start a new burndown for the second week (and then you can ignore like you did the one for the first week).